Re: [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths

On Wed, Jan 17, 2018 at 11:26:08AM -0800, Linus Torvalds wrote: > But there are about ~100 set_fs() calls in generic code, and some of > those really are pretty fundamental. Doing things like "kernel_read()" > without set_fs() is basically impossible. Not if we move to iov_iter or iov_iter-like

Re: [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths

On Wed, Jan 17, 2018 at 11:26:08AM -0800, Linus Torvalds wrote: > But there are about ~100 set_fs() calls in generic code, and some of > those really are pretty fundamental. Doing things like "kernel_read()" > without set_fs() is basically impossible. Not if we move to iov_iter or iov_iter-like

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

On Thu, Jan 18, 2018 at 02:48:23PM +0100, Peter Zijlstra wrote: > From: Thomas Gleixner > > Add the minimal infrastructure to control the speculation control feature. > > - Integrate it into the spectre_v2 coammand line parser and the mitigation >selector function. The

Re: [PATCH v5 4/4] PCI/DPC: Enumerate the devices after DPC trigger event

On 1/18/2018 12:32 AM, p...@codeaurora.org wrote: > On 2018-01-18 08:26, Keith Busch wrote: >> On Wed, Jan 17, 2018 at 08:27:39AM -0800, Sinan Kaya wrote: >>> On 1/17/2018 5:37 AM, Oza Pawandeep wrote: >>> > +static bool dpc_wait_link_active(struct pci_dev *pdev) >>> > +{ >>> >>> I think you can

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

On Thu, Jan 18, 2018 at 02:48:23PM +0100, Peter Zijlstra wrote: > From: Thomas Gleixner > > Add the minimal infrastructure to control the speculation control feature. > > - Integrate it into the spectre_v2 coammand line parser and the mitigation >selector function. The conditional selector

Re: [PATCH v5 4/4] PCI/DPC: Enumerate the devices after DPC trigger event

On 1/18/2018 12:32 AM, p...@codeaurora.org wrote: > On 2018-01-18 08:26, Keith Busch wrote: >> On Wed, Jan 17, 2018 at 08:27:39AM -0800, Sinan Kaya wrote: >>> On 1/17/2018 5:37 AM, Oza Pawandeep wrote: >>> > +static bool dpc_wait_link_active(struct pci_dev *pdev) >>> > +{ >>> >>> I think you can

Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC

On 1/18/2018 12:57 AM, p...@codeaurora.org wrote: > On 2018-01-18 10:47, p...@codeaurora.org wrote: >> On 2018-01-17 22:16, Sinan Kaya wrote: >>> On 1/17/2018 5:37 AM, Oza Pawandeep wrote: +++ b/include/linux/dpc.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +

Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC

On 1/18/2018 12:57 AM, p...@codeaurora.org wrote: > On 2018-01-18 10:47, p...@codeaurora.org wrote: >> On 2018-01-17 22:16, Sinan Kaya wrote: >>> On 1/17/2018 5:37 AM, Oza Pawandeep wrote: +++ b/include/linux/dpc.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +

Re: [PATCH v4] perf report: Fix regression when decoding intelPT traces

Em Wed, Jan 10, 2018 at 01:31:52PM -0700, Mathieu Poirier escreveu: > Commit (93d10af26bb7 perf tools: Optimize sample parsing for ordered > events) breaks intelPT trace decoding by invariably returning an error if > the event type isn't a PERF_SAMPLE_TIME. Adrian, have you had the chance of

Re: [PATCH v4] perf report: Fix regression when decoding intelPT traces

Em Wed, Jan 10, 2018 at 01:31:52PM -0700, Mathieu Poirier escreveu: > Commit (93d10af26bb7 perf tools: Optimize sample parsing for ordered > events) breaks intelPT trace decoding by invariably returning an error if > the event type isn't a PERF_SAMPLE_TIME. Adrian, have you had the chance of

Re: [RFC][PATCH] get rid of the use of set_fs() (by way of kernel_recvmsg()) in sunrpc

> We could turn ->msg_control/->msg_controllen into another > iov_iter, but seeing that we never do scatter-gather for those > IMO that would be a massive overkill. A flag controlling whether > ->msg_control is kernel or userland pointer would do, especially > since we already have a flag

Re: [RFC][PATCH] get rid of the use of set_fs() (by way of kernel_recvmsg()) in sunrpc

> We could turn ->msg_control/->msg_controllen into another > iov_iter, but seeing that we never do scatter-gather for those > IMO that would be a massive overkill. A flag controlling whether > ->msg_control is kernel or userland pointer would do, especially > since we already have a flag

[PATCH 5/5] irqchip/irq-gic-v3-its: Mark an array of text strings as "const"

From: Markus Elfring Date: Thu, 18 Jan 2018 17:05:34 +0100 The script "checkpatch.pl" pointed information out like the following. WARNING: static const char * array should probably be static const char * const Thus fix the affected source code place.

[PATCH 5/5] irqchip/irq-gic-v3-its: Mark an array of text strings as "const"

From: Markus Elfring Date: Thu, 18 Jan 2018 17:05:34 +0100 The script "checkpatch.pl" pointed information out like the following. WARNING: static const char * array should probably be static const char * const Thus fix the affected source code place. Signed-off-by: Markus Elfring ---

Re: [PATCH v4] perf report: Fix regression when decoding intelPT traces

Em Wed, Jan 10, 2018 at 01:31:52PM -0700, Mathieu Poirier escreveu: > Commit (93d10af26bb7 perf tools: Optimize sample parsing for ordered > events) breaks intelPT trace decoding by invariably returning an error if > the event type isn't a PERF_SAMPLE_TIME. Thanks, applied. > With this patch

Re: [PATCH v4] perf report: Fix regression when decoding intelPT traces

Em Wed, Jan 10, 2018 at 01:31:52PM -0700, Mathieu Poirier escreveu: > Commit (93d10af26bb7 perf tools: Optimize sample parsing for ordered > events) breaks intelPT trace decoding by invariably returning an error if > the event type isn't a PERF_SAMPLE_TIME. Thanks, applied. > With this patch

[PATCH 4/5] irqchip/irq-gic-v3-its: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Thu, 18 Jan 2018 16:54:16 +0100 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 4/5] irqchip/irq-gic-v3-its: Delete an error message for a failed memory allocation in two functions

From: Markus Elfring Date: Thu, 18 Jan 2018 16:54:16 +0100 Omit an extra message for a memory allocation failure in these functions. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/irqchip/irq-gic-v3-its.c | 8 ++-- 1 file changed, 2

[PATCH 3/5] irqchip/irq-gic-v2m: Mark a of_device_id variable as "const"

From: Markus Elfring Date: Thu, 18 Jan 2018 16:33:43 +0100 The script "checkpatch.pl" pointed information out like the following. WARNING: struct of_device_id should normally be const Thus fix the affected source code place. Signed-off-by: Markus Elfring

Re: [PATCH 20/35] x86: Force asm-goto

On Thu, 2018-01-18 at 14:48 +0100, Peter Zijlstra wrote: > Now that we have objtool to validate the correctness of asm-goto > constructs we can start using it to guarantee the absence of dynamic > branches (and thus speculation). > > A primary prerequisite for this is of course that the compiler

Re: [PATCH 20/35] x86: Force asm-goto

On Thu, 2018-01-18 at 14:48 +0100, Peter Zijlstra wrote: > Now that we have objtool to validate the correctness of asm-goto > constructs we can start using it to guarantee the absence of dynamic > branches (and thus speculation). > > A primary prerequisite for this is of course that the compiler

[PATCH 3/5] irqchip/irq-gic-v2m: Mark a of_device_id variable as "const"

From: Markus Elfring Date: Thu, 18 Jan 2018 16:33:43 +0100 The script "checkpatch.pl" pointed information out like the following. WARNING: struct of_device_id should normally be const Thus fix the affected source code place. Signed-off-by: Markus Elfring --- drivers/irqchip/irq-gic-v2m.c |

[PATCH 2/5] irqchip/irq-gic-v2m: Improve a size determination in gicv2m_init_one()

From: Markus Elfring Date: Thu, 18 Jan 2018 16:07:41 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 2/5] irqchip/irq-gic-v2m: Improve a size determination in gicv2m_init_one()

From: Markus Elfring Date: Thu, 18 Jan 2018 16:07:41 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was

[PATCH 1/5] irqchip/irq-gic-v2m: Delete an error message for a failed memory allocation in gicv2m_init_one()

From: Markus Elfring Date: Thu, 18 Jan 2018 15:44:01 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/5] irqchip/irq-gic-v2m: Delete an error message for a failed memory allocation in gicv2m_init_one()

From: Markus Elfring Date: Thu, 18 Jan 2018 15:44:01 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/irqchip/irq-gic-v2m.c | 4 +--- 1 file changed, 1

Re: [PATCH 29/35] x86/speculation: Add IPBP support

On Thu, Jan 18, 2018 at 02:48:29PM +0100, Peter Zijlstra wrote: > From: Thomas Gleixner > > Signed-off-by: Thomas Gleixner > Signed-off-by: Peter Zijlstra (Intel) s/IPBP/IBPB/ in subject. -- Josh

Re: [PATCH 29/35] x86/speculation: Add IPBP support

On Thu, Jan 18, 2018 at 02:48:29PM +0100, Peter Zijlstra wrote: > From: Thomas Gleixner > > Signed-off-by: Thomas Gleixner > Signed-off-by: Peter Zijlstra (Intel) s/IPBP/IBPB/ in subject. -- Josh

[PATCH 0/5] irqchip/irq-gic: Adjustments for three function implementations

From: Markus Elfring Date: Thu, 18 Jan 2018 17:17:34 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (5): Delete an error message for a failed memory allocation in gicv2m_init_one() Improve a size

[PATCH 0/5] irqchip/irq-gic: Adjustments for three function implementations

From: Markus Elfring Date: Thu, 18 Jan 2018 17:17:34 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (5): Delete an error message for a failed memory allocation in gicv2m_init_one() Improve a size determination in gicv2m_init_one()

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

On Wed, Jan 17, 2018 at 07:43:51PM +0530, PrasannaKumar Muralidharan wrote: > Hi Jarkko, > > On 14 November 2017 at 20:02, Jarkko Sakkinen > wrote: > > On Sun, Nov 12, 2017 at 10:53:35AM +0530, PrasannaKumar Muralidharan wrote: > >> Did basic check on tpm rng

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

On Wed, Jan 17, 2018 at 07:43:51PM +0530, PrasannaKumar Muralidharan wrote: > Hi Jarkko, > > On 14 November 2017 at 20:02, Jarkko Sakkinen > wrote: > > On Sun, Nov 12, 2017 at 10:53:35AM +0530, PrasannaKumar Muralidharan wrote: > >> Did basic check on tpm rng patch, it works fine. As it depends

Re: [PATCH v3 02/12] clk: sunxi-ng: Change formula for NKMP PLLs

Hi, Dne četrtek, 18. januar 2018 ob 11:58:41 CET je Maxime Ripard napisal(a): > Hi, > > On Wed, Jan 17, 2018 at 09:14:11PM +0100, Jernej Skrabec wrote: > > This commit changes formula from this: > > > > Freq = (parent_freq * N * K) / (M * P) > > > > to this: > > > > Freq = (parent_freq / M) *

Re: [PATCH v3 02/12] clk: sunxi-ng: Change formula for NKMP PLLs

Hi, Dne četrtek, 18. januar 2018 ob 11:58:41 CET je Maxime Ripard napisal(a): > Hi, > > On Wed, Jan 17, 2018 at 09:14:11PM +0100, Jernej Skrabec wrote: > > This commit changes formula from this: > > > > Freq = (parent_freq * N * K) / (M * P) > > > > to this: > > > > Freq = (parent_freq / M) *

Re: [PATCH] cifs: remove redundant duplicated assignment of pointer 'node'

merged into cifs-2.6.git for-next thx On Wed, Jan 17, 2018 at 5:11 PM, Ronnie Sahlberg wrote: > Reviewed-by: Ronnie Sahlberg > > > - Original Message - > From: "Colin King" > To: "Steve French" ,

Re: [PATCH] cifs: remove redundant duplicated assignment of pointer 'node'

merged into cifs-2.6.git for-next thx On Wed, Jan 17, 2018 at 5:11 PM, Ronnie Sahlberg wrote: > Reviewed-by: Ronnie Sahlberg > > > - Original Message - > From: "Colin King" > To: "Steve French" , linux-c...@vger.kernel.org, > samba-techni...@lists.samba.org > Cc:

Re: [PATCH] scripts/gdb: fix get_thread_info

On 2018-01-18 22:01, Xi Kangjie wrote: > Since kernel 4.9, the thread_info has been moved into task_struct, > no longer locates at the bottom of kernel stack. > > See commits: > - commit c65eacbe290b ("sched/core: Allow putting thread_info into > task_struct") > - commit 15f4eae70d36 ("x86: Move

Re: [PATCH] scripts/gdb: fix get_thread_info

On 2018-01-18 22:01, Xi Kangjie wrote: > Since kernel 4.9, the thread_info has been moved into task_struct, > no longer locates at the bottom of kernel stack. > > See commits: > - commit c65eacbe290b ("sched/core: Allow putting thread_info into > task_struct") > - commit 15f4eae70d36 ("x86: Move

[PATCH v2 tip/master 3/3] kprobes/x86: Disable optimizing on the function jumps to indirect thunk

Since indirect jump instructions will be replaced by jump to __x86_indirect_thunk_*, those jmp instruction must be treated as an indirect jump. Since optprobe prohibits to optimize probes in the function which uses an indirect jump, it also needs to find out the function which jump to

[PATCH v2 tip/master 3/3] kprobes/x86: Disable optimizing on the function jumps to indirect thunk

Since indirect jump instructions will be replaced by jump to __x86_indirect_thunk_*, those jmp instruction must be treated as an indirect jump. Since optprobe prohibits to optimize probes in the function which uses an indirect jump, it also needs to find out the function which jump to

[PATCH v2 tip/master 2/3] kprobes/x86: Blacklist indirect thunk functions for kprobes

Mark __x86_indirect_thunk_* functions as blacklist for kprobes because those functions can be called from anywhere in the kernel including blacklist functions of kprobes. Signed-off-by: Masami Hiramatsu --- arch/x86/lib/retpoline.S |3 ++- 1 file changed, 2

[PATCH v2 tip/master 2/3] kprobes/x86: Blacklist indirect thunk functions for kprobes

Mark __x86_indirect_thunk_* functions as blacklist for kprobes because those functions can be called from anywhere in the kernel including blacklist functions of kprobes. Signed-off-by: Masami Hiramatsu --- arch/x86/lib/retpoline.S |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[PATCH v2 tip/master 1/3] retpoline: Introduce start/end markers of indirect thunk

Introduce start/end markers of __x86_indirect_thunk_* functions. To make it easy, consolidate .text.__x86.indirect_thunk.* sections to one .text.__x86.indirect_thunk section and put it in the end of kernel text section and adds __indirect_thunk_start/end so that other subsystem (e.g. kprobes) can

[PATCH v2 tip/master 1/3] retpoline: Introduce start/end markers of indirect thunk

Introduce start/end markers of __x86_indirect_thunk_* functions. To make it easy, consolidate .text.__x86.indirect_thunk.* sections to one .text.__x86.indirect_thunk section and put it in the end of kernel text section and adds __indirect_thunk_start/end so that other subsystem (e.g. kprobes) can

[PATCH v2 tip/master 0/3] kprobes/x86: retpoline: Fix kprobes for retpoline

Hi, This is the 2nd version of the series to fix kprobes issues on the kernel with CONFIG_RETPOLINE=y. - [1/3]: This introduces __x86_indirect_thunk_* boundary symbols so that kprobes easily identify those functions. - [2/3]: Mark __x86_indirect_thunk_* as blacklisted function

[PATCH v2 tip/master 0/3] kprobes/x86: retpoline: Fix kprobes for retpoline

Hi, This is the 2nd version of the series to fix kprobes issues on the kernel with CONFIG_RETPOLINE=y. - [1/3]: This introduces __x86_indirect_thunk_* boundary symbols so that kprobes easily identify those functions. - [2/3]: Mark __x86_indirect_thunk_* as blacklisted function

[RFC 1/6] softirq: Add softirq_groups boot parameter

ksoftirqd thread allows to defer softirqs if the system is under storm. While it prevents userspace from cpu-time starving, it increases latencies for other softirqs (that are not raised under storm). As creation of one ksoftirqd thread per-each-softirq-per-cpu will be insane on a huge machines,

[RFC 1/6] softirq: Add softirq_groups boot parameter

ksoftirqd thread allows to defer softirqs if the system is under storm. While it prevents userspace from cpu-time starving, it increases latencies for other softirqs (that are not raised under storm). As creation of one ksoftirqd thread per-each-softirq-per-cpu will be insane on a huge machines,

[RFC 3/6] softirq: Add reverse group-to-softirq map

For faster operation with pending mask: pending &= group_to_softirq[group_nr]; Signed-off-by: Dmitry Safonov --- kernel/softirq.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/kernel/softirq.c b/kernel/softirq.c index ca8c3db4570d..7de5791c08f9 100644

[RFC 5/6] softirq: Add time accounting per-softirq type

Warning: not a merge-ready in any sense As discussed, softirqs will be deferred or processed right away according to how much time this type of softirq spent on CPU. This will improve e.g. handling of net-rx softirqs during packet storm and also give fair slice of cpu time for a userspace process

[RFC 5/6] softirq: Add time accounting per-softirq type

Warning: not a merge-ready in any sense As discussed, softirqs will be deferred or processed right away according to how much time this type of softirq spent on CPU. This will improve e.g. handling of net-rx softirqs during packet storm and also give fair slice of cpu time for a userspace process

[RFC 3/6] softirq: Add reverse group-to-softirq map

For faster operation with pending mask: pending &= group_to_softirq[group_nr]; Signed-off-by: Dmitry Safonov --- kernel/softirq.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/kernel/softirq.c b/kernel/softirq.c index ca8c3db4570d..7de5791c08f9 100644 ---

[RFC 4/6] softirq: Run per-group per-cpu ksoftirqd thread

Running one ksoftirqd per-cpu allows to defer processing softirqs under storm. But having only one ksoftirqd thread for that make it worse for other kinds of softirqs. As we check if (ksoftirqd_running()) and defer all softirqs till ksoftirqd time-slice it introduces latencies. While it's

[RFC 6/6] softirq/sched: Account si cpu time to ksoftirqd(s)

Warning: non-merge-ready in any sense Under CONFIG_FAIR_SOFTIRQ_SCHEDULE each sched tick will account cpu time spent on processing softirqs to ksoftirqd of the softirq's group. Update then ksoftirqd->se.sum_exec_runtime and recalculate ksoftirqd->se.vruntime. Use CFS's vrutime to decide if

[RFC 4/6] softirq: Run per-group per-cpu ksoftirqd thread

Running one ksoftirqd per-cpu allows to defer processing softirqs under storm. But having only one ksoftirqd thread for that make it worse for other kinds of softirqs. As we check if (ksoftirqd_running()) and defer all softirqs till ksoftirqd time-slice it introduces latencies. While it's

[RFC 6/6] softirq/sched: Account si cpu time to ksoftirqd(s)

Warning: non-merge-ready in any sense Under CONFIG_FAIR_SOFTIRQ_SCHEDULE each sched tick will account cpu time spent on processing softirqs to ksoftirqd of the softirq's group. Update then ksoftirqd->se.sum_exec_runtime and recalculate ksoftirqd->se.vruntime. Use CFS's vrutime to decide if

[RFC 2/6] softirq: Introduce mask for __do_softirq()

__do_softirq() serves all pending softirqs. As we need to separate softirqs by different groups, we need to serve softirqs from one group and deffer softirqs from the other. Change __do_softirq() so it'll have a mask of softirqs it needs to serve instead of servicing all pending softirqs.

[RFC 2/6] softirq: Introduce mask for __do_softirq()

__do_softirq() serves all pending softirqs. As we need to separate softirqs by different groups, we need to serve softirqs from one group and deffer softirqs from the other. Change __do_softirq() so it'll have a mask of softirqs it needs to serve instead of servicing all pending softirqs.

[RFC 0/6] Multi-thread per-cpu ksoftirqd

Another attempt to solve softirq deferring problems. There are at least two problems, AFAIK: o deferring one softirq to ksoftirqd results in latencies for other (different type) softirqs by the reason of ksoftirqd_running() decision for deferring/servicing. o The logic in __do_softirq() that

[RFC 0/6] Multi-thread per-cpu ksoftirqd

Another attempt to solve softirq deferring problems. There are at least two problems, AFAIK: o deferring one softirq to ksoftirqd results in latencies for other (different type) softirqs by the reason of ksoftirqd_running() decision for deferring/servicing. o The logic in __do_softirq() that

[PATCH 2/2] RISC-V: Move to the new asm-generic IRQ handler

The old mechanism for handling IRQs on RISC-V was pretty ugly: the arch code looked at the Kconfig entry for our first-level irqchip driver and called into it directly. This patch uses the new asm-generic IRQ handling infastructure, which essentially just deletes a bunch of code. This does add

Use arm64's scheme for registering first-level IRQ handlers on RISC-V

This patch set has been sitting around for a while, but it got a bit lost in the shuffle. In RISC-V land we currently couple do_IRQ (the C entry point for interrupt handling) to our first-level interrupt controller. While this isn't completely crazy (as the first-level interrupt controller is

Re: [PATCH v6 00/99] XArray version 6

On Wed, Jan 17, 2018 at 12:20:24PM -0800, Matthew Wilcox wrote: > From: Matthew Wilcox > > This version of the XArray has no known bugs. I've booted this patchset on 2 boxes, both had random problems during boot. On one I was not able to diagnose what went wrong. On the

Re: [PATCH v6 00/99] XArray version 6

On Wed, Jan 17, 2018 at 12:20:24PM -0800, Matthew Wilcox wrote: > From: Matthew Wilcox > > This version of the XArray has no known bugs. I've booted this patchset on 2 boxes, both had random problems during boot. On one I was not able to diagnose what went wrong. On the other one the system

[PATCH 2/2] RISC-V: Move to the new asm-generic IRQ handler

The old mechanism for handling IRQs on RISC-V was pretty ugly: the arch code looked at the Kconfig entry for our first-level irqchip driver and called into it directly. This patch uses the new asm-generic IRQ handling infastructure, which essentially just deletes a bunch of code. This does add

Use arm64's scheme for registering first-level IRQ handlers on RISC-V

This patch set has been sitting around for a while, but it got a bit lost in the shuffle. In RISC-V land we currently couple do_IRQ (the C entry point for interrupt handling) to our first-level interrupt controller. While this isn't completely crazy (as the first-level interrupt controller is

[PATCH 1/2] asm-generic: Add a generic set_handle_irq

From: Palmer Dabbelt I've copied this from arm64, but it appears to be the same code that's in arm and openrisc. I wanted to use it for RISC-V's interrupt handler as well, so despite this only being a handful of lines of code it seems worth having a generic version -- if it

[PATCH 1/2] asm-generic: Add a generic set_handle_irq

From: Palmer Dabbelt I've copied this from arm64, but it appears to be the same code that's in arm and openrisc. I wanted to use it for RISC-V's interrupt handler as well, so despite this only being a handful of lines of code it seems worth having a generic version -- if it existed when we

Re: [PATCH 1/2] asm-generic: Add a generic set_handle_irq

I think this should not be asm-generic and lib, but kernel/irq/handle.c and include/linux/irq.h, under the CONFIG_MULTI_IRQ_HANDLER symbol already used by arm. Also for completeness of the series please convert arm, arm64 and openrisc over to the generic version. Last but not least I think

Re: [PATCH 1/2] asm-generic: Add a generic set_handle_irq

I think this should not be asm-generic and lib, but kernel/irq/handle.c and include/linux/irq.h, under the CONFIG_MULTI_IRQ_HANDLER symbol already used by arm. Also for completeness of the series please convert arm, arm64 and openrisc over to the generic version. Last but not least I think

Re: [PATCH] scripts/gdb: fix get_thread_info

On 2018-01-18 16:47, Kieran Bingham wrote: > > On 18/01/18 15:43, Jan Kiszka wrote: >> On 2018-01-18 22:01, Xi Kangjie wrote: >>> Since kernel 4.9, the thread_info has been moved into task_struct, >>> no longer locates at the bottom of kernel stack. >>> >>> See commits: >>> - commit c65eacbe290b

Re: [PATCH] x86/mce: Make machine check speculation protected

On Thu, Jan 18, 2018 at 04:28:26PM +0100, Thomas Gleixner wrote: > The machine check idtentry uses an indirect branch directly from the low > level code. This evades the speculation protection. > > Replace it by a direct call into C code and issue the indirect call there > so the compiler can

Re: [PATCH] scripts/gdb: fix get_thread_info

On 2018-01-18 16:47, Kieran Bingham wrote: > > On 18/01/18 15:43, Jan Kiszka wrote: >> On 2018-01-18 22:01, Xi Kangjie wrote: >>> Since kernel 4.9, the thread_info has been moved into task_struct, >>> no longer locates at the bottom of kernel stack. >>> >>> See commits: >>> - commit c65eacbe290b

Re: [PATCH] x86/mce: Make machine check speculation protected

On Thu, Jan 18, 2018 at 04:28:26PM +0100, Thomas Gleixner wrote: > The machine check idtentry uses an indirect branch directly from the low > level code. This evades the speculation protection. > > Replace it by a direct call into C code and issue the indirect call there > so the compiler can

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu, Jan 18, 2018 at 06:45:00AM -0800, Dave Hansen wrote: > On 01/18/2018 04:25 AM, Kirill A. Shutemov wrote: > > [ 10.084024] diff: -858690919 > > [ 10.084258] hpage_nr_pages: 1 > > [ 10.084386] check1: 0 > > [ 10.084478] check2: 0 > ... > > diff --git a/mm/page_vma_mapped.c

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu, Jan 18, 2018 at 06:45:00AM -0800, Dave Hansen wrote: > On 01/18/2018 04:25 AM, Kirill A. Shutemov wrote: > > [ 10.084024] diff: -858690919 > > [ 10.084258] hpage_nr_pages: 1 > > [ 10.084386] check1: 0 > > [ 10.084478] check2: 0 > ... > > diff --git a/mm/page_vma_mapped.c

Re: [PATCH] MIPS: use generic GCC library routines from lib/

On Wed, 17 Jan 2018 05:34:18 PST (-0800), antonynpav...@gmail.com wrote: On Wed, 17 Jan 2018 09:03:48 + Matt Redfearn wrote: Hi, On Wed, Jan 17, 2018 at 09:51:21AM +0300, Antony Pavlov wrote: > The commit b35cd9884fa5 ("lib: Add shared copies of > some GCC library

Re: [PATCH] MIPS: use generic GCC library routines from lib/

On Wed, 17 Jan 2018 01:03:48 PST (-0800), matt.redfe...@mips.com wrote: Hi, On Wed, Jan 17, 2018 at 09:51:21AM +0300, Antony Pavlov wrote: The commit b35cd9884fa5 ("lib: Add shared copies of some GCC library routines") makes it possible to share generic GCC library routines by several

Re: [PATCH] MIPS: use generic GCC library routines from lib/

On Wed, 17 Jan 2018 05:34:18 PST (-0800), antonynpav...@gmail.com wrote: On Wed, 17 Jan 2018 09:03:48 + Matt Redfearn wrote: Hi, On Wed, Jan 17, 2018 at 09:51:21AM +0300, Antony Pavlov wrote: > The commit b35cd9884fa5 ("lib: Add shared copies of > some GCC library routines") makes it

Re: [PATCH] MIPS: use generic GCC library routines from lib/

On Wed, 17 Jan 2018 01:03:48 PST (-0800), matt.redfe...@mips.com wrote: Hi, On Wed, Jan 17, 2018 at 09:51:21AM +0300, Antony Pavlov wrote: The commit b35cd9884fa5 ("lib: Add shared copies of some GCC library routines") makes it possible to share generic GCC library routines by several

[PATCH] pinctrl: at91-pio4: add support for drive-strength property

Add support for the drive-strength property. Usually its value is expressed in mA. Since the numeric value depends on VDDIOP voltage, the controller uses low, medium and high to define the drive-strengh. The PIO controller accepts two values for the low drive: 0 or 1. Most of the time, we don't

[PATCH] pinctrl: at91-pio4: add support for drive-strength property

Add support for the drive-strength property. Usually its value is expressed in mA. Since the numeric value depends on VDDIOP voltage, the controller uses low, medium and high to define the drive-strengh. The PIO controller accepts two values for the low drive: 0 or 1. Most of the time, we don't

Re: [PATCH] Support tablet mode switch for Dell laptops

On Thu, Jan 18, 2018 at 4:23 PM, wrote: > AFAIK we don't have a public specification for the ACPI interface > that intel-vbtn uses, it's all reverse engineered. > > I think the appropriate thing to do would be open a kernel Bugzilla for your > issue and attach: > 1)

Re: [PATCH] Support tablet mode switch for Dell laptops

On Thu, Jan 18, 2018 at 4:23 PM, wrote: > AFAIK we don't have a public specification for the ACPI interface > that intel-vbtn uses, it's all reverse engineered. > > I think the appropriate thing to do would be open a kernel Bugzilla for your > issue and attach: > 1) kernel log without your patch

Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

On Wed, Jan 17, 2018 at 10:50 PM, Benjamin Poirier wrote: > It was reported that emulated e1000e devices in vmware esxi 6.5 Build > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver > overrun interrupt bursts", v4.15-rc1). Some tracing shows that after >

Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

On Wed, Jan 17, 2018 at 10:50 PM, Benjamin Poirier wrote: > It was reported that emulated e1000e devices in vmware esxi 6.5 Build > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver > overrun interrupt bursts", v4.15-rc1). Some tracing shows that after >

[PATCH v3 2/6] riscv/ftrace: Add dynamic function tracer support

We now have dynamic ftrace with the following added items: * ftrace_make_call, ftrace_make_nop (in kernel/ftrace.c) The two functions turns any recorded call site of filtered functions into a call to ftrace_caller or nops * ftracce_update_ftrace_func (in kernel/ftrace.c) turns the stub

Re: aio poll, io_pgetevents and a new in-kernel poll API V3

FYI, this kernel has issues. It will boot up, but I don't have networking, and even rebooting doesn't succeed. I'm looking into it. -Jeff Christoph Hellwig writes: > Hi all, > > this series adds support for the IOCB_CMD_POLL operation to poll for the > readyness of file

[PATCH v3 1/6] riscv/ftrace: Add RECORD_MCOUNT support

Now recordmcount.pl recognizes RISC-V object files. For the mechanism to work, we have to disable the linker relaxation. Cc: Greentime Hu Signed-off-by: Alan Kao --- arch/riscv/Kconfig | 1 + arch/riscv/Makefile | 3 +++

Re: aio poll, io_pgetevents and a new in-kernel poll API V3

FYI, this kernel has issues. It will boot up, but I don't have networking, and even rebooting doesn't succeed. I'm looking into it. -Jeff Christoph Hellwig writes: > Hi all, > > this series adds support for the IOCB_CMD_POLL operation to poll for the > readyness of file descriptors using the

[PATCH v3 1/6] riscv/ftrace: Add RECORD_MCOUNT support

Now recordmcount.pl recognizes RISC-V object files. For the mechanism to work, we have to disable the linker relaxation. Cc: Greentime Hu Signed-off-by: Alan Kao --- arch/riscv/Kconfig | 1 + arch/riscv/Makefile | 3 +++ scripts/recordmcount.pl | 5 + 3 files changed, 9

[PATCH v3 2/6] riscv/ftrace: Add dynamic function tracer support

We now have dynamic ftrace with the following added items: * ftrace_make_call, ftrace_make_nop (in kernel/ftrace.c) The two functions turns any recorded call site of filtered functions into a call to ftrace_caller or nops * ftracce_update_ftrace_func (in kernel/ftrace.c) turns the stub

staging: lustre: Cleanup of obd_class.h

Here are the remaining patches rebased on the current staging-testing.

Re: [PATCH] net: ethernet: cavium: Correct Cacivum Thunderx nicvf/nicpf modules names

Self NACK to this one, subject line typo, sorry. Vadim On Thu, Jan 18, 2018 at 07:42:40AM -0800, Vadim Lomovtsev wrote: > From: Vadim Lomovtsev > > It was found that ethtool provides unexisting module name while > it queries the specified network device for

staging: lustre: Cleanup of obd_class.h

Here are the remaining patches rebased on the current staging-testing.

Re: [PATCH] net: ethernet: cavium: Correct Cacivum Thunderx nicvf/nicpf modules names

Self NACK to this one, subject line typo, sorry. Vadim On Thu, Jan 18, 2018 at 07:42:40AM -0800, Vadim Lomovtsev wrote: > From: Vadim Lomovtsev > > It was found that ethtool provides unexisting module name while > it queries the specified network device for associated driver > information. >

Re: [PATCH] scripts/gdb: fix get_thread_info

On 18/01/18 15:43, Jan Kiszka wrote: > On 2018-01-18 22:01, Xi Kangjie wrote: >> Since kernel 4.9, the thread_info has been moved into task_struct, >> no longer locates at the bottom of kernel stack. >> >> See commits: >> - commit c65eacbe290b ("sched/core: Allow putting thread_info into >>

Re: [PATCH] scripts/gdb: fix get_thread_info

On 18/01/18 15:43, Jan Kiszka wrote: > On 2018-01-18 22:01, Xi Kangjie wrote: >> Since kernel 4.9, the thread_info has been moved into task_struct, >> no longer locates at the bottom of kernel stack. >> >> See commits: >> - commit c65eacbe290b ("sched/core: Allow putting thread_info into >>

Re: [PATCH] x86/mce: Make machine check speculation protected

On Thu, 2018-01-18 at 16:28 +0100, Thomas Gleixner wrote: > The machine check idtentry uses an indirect branch directly from the low > level code. This evades the speculation protection. > > Replace it by a direct call into C code and issue the indirect call there > so the compiler can apply the

Re: [PATCH] x86/mce: Make machine check speculation protected

On Thu, 2018-01-18 at 16:28 +0100, Thomas Gleixner wrote: > The machine check idtentry uses an indirect branch directly from the low > level code. This evades the speculation protection. > > Replace it by a direct call into C code and issue the indirect call there > so the compiler can apply the

<    6   7   8   9   10   11   12   13   14   15   >