[PATCH 17/23] x86, kaiser: map virtually-addressed performance monitoring buffers

From: Hugh Dickins The BTS and PEBS buffers both have their virtual addresses programmed into the hardware. This means that we have to access them via the page tables. The times that the hardware accesses these are entirely dependent on how the performance monitoring

[PATCH 20/23] x86, mm: put mmu-to-h/w ASID translation in one place

We effectively have two ASID types: 1. The one stored in the mmu_context that goes from 0->5 2. The one we program into the hardware that goes from 1->6 Let's just put the +1 in a single place which gives us a nice place to comment. KAISER will also need to, given an ASID, know which hardware

[PATCH 12/23] x86, kaiser: map dynamically-allocated LDTs

Normally, a process just has a NULL mm->context.ldt. But, we have a syscall for a process to set a new one. If a process does that, we need to map the new LDT. The original KAISER patch missed this case. Signed-off-by: Dave Hansen Cc: Moritz Lipp

[PATCH 17/23] x86, kaiser: map virtually-addressed performance monitoring buffers

From: Hugh Dickins The BTS and PEBS buffers both have their virtual addresses programmed into the hardware. This means that we have to access them via the page tables. The times that the hardware accesses these are entirely dependent on how the performance monitoring hardware events are set

[PATCH 20/23] x86, mm: put mmu-to-h/w ASID translation in one place

We effectively have two ASID types: 1. The one stored in the mmu_context that goes from 0->5 2. The one we program into the hardware that goes from 1->6 Let's just put the +1 in a single place which gives us a nice place to comment. KAISER will also need to, given an ASID, know which hardware

[PATCH 12/23] x86, kaiser: map dynamically-allocated LDTs

Normally, a process just has a NULL mm->context.ldt. But, we have a syscall for a process to set a new one. If a process does that, we need to map the new LDT. The original KAISER patch missed this case. Signed-off-by: Dave Hansen Cc: Moritz Lipp Cc: Daniel Gruss Cc: Michael Schwarz Cc:

[PATCH 22/23] x86, kaiser: use PCID feature to make user and kernel switches faster

Short summary: Use x86 PCID feature to avoid flushing the TLB at all interrupts and syscalls. Speed them up. Makes context switches and TLB flushing slower. Background: KAISER keeps two copies of the page tables. We switch between them with the the CR3 register. But, CR3 was really designed

[PATCH 22/23] x86, kaiser: use PCID feature to make user and kernel switches faster

Short summary: Use x86 PCID feature to avoid flushing the TLB at all interrupts and syscalls. Speed them up. Makes context switches and TLB flushing slower. Background: KAISER keeps two copies of the page tables. We switch between them with the the CR3 register. But, CR3 was really designed

[PATCH 09/23] x86, kaiser: allow NX to be set in p4d/pgd

We protect user portion of the kernel page tables with the NX bit to cripple it. But, that trips the p4d/pgd_bad() checks. Make sure it does not do that. Signed-off-by: Dave Hansen Cc: Moritz Lipp Cc: Daniel Gruss

[PATCH 09/23] x86, kaiser: allow NX to be set in p4d/pgd

We protect user portion of the kernel page tables with the NX bit to cripple it. But, that trips the p4d/pgd_bad() checks. Make sure it does not do that. Signed-off-by: Dave Hansen Cc: Moritz Lipp Cc: Daniel Gruss Cc: Michael Schwarz Cc: Andy Lutomirski Cc: Linus Torvalds Cc: Kees Cook

[PATCH 19/23] x86, mm: remove hard-coded ASID limit checks

First, it's nice to remove the magic numbers. Second, KAISER is going to eat up half of the available ASID space. We do not use it today, but we need to at least spell out this new restriction. Signed-off-by: Dave Hansen Cc: Moritz Lipp

[PATCH 21/23] x86, pcid, kaiser: allow flushing for future ASID switches

If we change the page tables in such a way that we need an invalidation of all contexts (aka. PCIDs / ASIDs) we can actively invalidate them by: 1. INVPCID for each PCID (works for single pages too). 2. Load CR3 with each PCID without the NOFLUSH bit set 3. Load CR3 with the NOFLUSH bit set

[PATCH 19/23] x86, mm: remove hard-coded ASID limit checks

First, it's nice to remove the magic numbers. Second, KAISER is going to eat up half of the available ASID space. We do not use it today, but we need to at least spell out this new restriction. Signed-off-by: Dave Hansen Cc: Moritz Lipp Cc: Daniel Gruss Cc: Michael Schwarz Cc: Andy

[PATCH 21/23] x86, pcid, kaiser: allow flushing for future ASID switches

If we change the page tables in such a way that we need an invalidation of all contexts (aka. PCIDs / ASIDs) we can actively invalidate them by: 1. INVPCID for each PCID (works for single pages too). 2. Load CR3 with each PCID without the NOFLUSH bit set 3. Load CR3 with the NOFLUSH bit set

[PATCH 23/23] x86, kaiser: add Kconfig

PARAVIRT generally requires that the kernel not manage its own page tables. It also means that the hypervisor and kernel must agree wholeheartedly about what format the page tables are in and what they contain. KAISER, unfortunately, changes the rules and they can not be used together. I've

[PATCH 23/23] x86, kaiser: add Kconfig

PARAVIRT generally requires that the kernel not manage its own page tables. It also means that the hypervisor and kernel must agree wholeheartedly about what format the page tables are in and what they contain. KAISER, unfortunately, changes the rules and they can not be used together. I've

[PATCH 18/23] x86, mm: Move CR3 construction functions

For flushing the TLB, we need to know which ASID has been programmed into the hardware. Since that differs from what is in 'cpu_tlbstate', we need to be able to transform the ASID in cpu_tlbstate to the one programmed into the hardware. It's not easy to include mmu_context.h into tlbflush.h, so

[PATCH 18/23] x86, mm: Move CR3 construction functions

For flushing the TLB, we need to know which ASID has been programmed into the hardware. Since that differs from what is in 'cpu_tlbstate', we need to be able to transform the ASID in cpu_tlbstate to the one programmed into the hardware. It's not easy to include mmu_context.h into tlbflush.h, so

[PATCH 00/23] KAISER: unmap most of the kernel from userspace page tables

tl;dr: KAISER makes it harder to defeat KASLR, but makes syscalls and interrupts slower. These patches are based on work from a team at Graz University of Technology posted here[1]. The major addition is support for Intel PCIDs which builds on top of Andy Lutomorski's PCID work merged for 4.14.

[PATCH 01/23] x86, kaiser: prepare assembly for entry/exit CR3 switching

This is largely code from Andy Lutomirski. I fixed a few bugs in it, and added a few SWITCH_TO_* spots. KAISER needs to switch to a different CR3 value when it enters the kernel and switch back when it exits. This essentially needs to be done before we leave assembly code. This is extra

[PATCH 00/23] KAISER: unmap most of the kernel from userspace page tables

tl;dr: KAISER makes it harder to defeat KASLR, but makes syscalls and interrupts slower. These patches are based on work from a team at Graz University of Technology posted here[1]. The major addition is support for Intel PCIDs which builds on top of Andy Lutomorski's PCID work merged for 4.14.

[PATCH 01/23] x86, kaiser: prepare assembly for entry/exit CR3 switching

This is largely code from Andy Lutomirski. I fixed a few bugs in it, and added a few SWITCH_TO_* spots. KAISER needs to switch to a different CR3 value when it enters the kernel and switch back when it exits. This essentially needs to be done before we leave assembly code. This is extra

Re: WARNING in tracepoint_probe_register_prio

On 10/31/2017 04:21 PM, Steven Rostedt wrote: > On Sun, 29 Oct 2017 14:24:01 -0700 > syzbot > > wrote: > >> syzkaller has found reproducer for the following crash on >> 36ef71cae353f88fd6e095e2aaa3e5953af1685d > > So

Re: WARNING in tracepoint_probe_register_prio

On 10/31/2017 04:21 PM, Steven Rostedt wrote: > On Sun, 29 Oct 2017 14:24:01 -0700 > syzbot > > wrote: > >> syzkaller has found reproducer for the following crash on >> 36ef71cae353f88fd6e095e2aaa3e5953af1685d > > So this fuzzer triggers this. > >>

Re: [PATCH] genirq: add mutex and rcu locking to irq_desc_tree

On Tue, 31 Oct 2017, Masahiro Yamada wrote: > Add a mutex to prevent concurrency on the updater side of the > irq_desc radix tree. The callers of insert/delete are already serialized by sparse_irq_lock. SO why would we need yet another mutex? > Add rcu_read_lock/unlock to the reader side so

Re: [PATCH] genirq: add mutex and rcu locking to irq_desc_tree

On Tue, 31 Oct 2017, Masahiro Yamada wrote: > Add a mutex to prevent concurrency on the updater side of the > irq_desc radix tree. The callers of insert/delete are already serialized by sparse_irq_lock. SO why would we need yet another mutex? > Add rcu_read_lock/unlock to the reader side so

Re: [RFC] xfs: fix reporting supported extra file attributes for statx()

On Tue, Oct 31, 2017 at 03:13:05PM -0700, Luis R. Rodriguez wrote: > statx(2) notes that any attribute that is not indicated as supported by > stx_attributes_mask has no usable value. Commit 5f955f26f3d42d ("xfs: report > crtime and attribute flags to statx") added support for informing userspace

Re: [RFC] xfs: fix reporting supported extra file attributes for statx()

On Tue, Oct 31, 2017 at 03:13:05PM -0700, Luis R. Rodriguez wrote: > statx(2) notes that any attribute that is not indicated as supported by > stx_attributes_mask has no usable value. Commit 5f955f26f3d42d ("xfs: report > crtime and attribute flags to statx") added support for informing userspace

[GIT PULL] Power management commit reverts for v4.14

Hi Linus, Since Geert reports additional problems with my PM QoS fix from the last week that have not been addressed by the most recent fixup on top of it, they both should better be reverted now and let's fix the original issue properly in 4.15. Please pull from the tag

[GIT PULL] Power management commit reverts for v4.14

Hi Linus, Since Geert reports additional problems with my PM QoS fix from the last week that have not been addressed by the most recent fixup on top of it, they both should better be reverted now and let's fix the original issue properly in 4.15. Please pull from the tag

Re: WARNING in tracepoint_probe_register_prio

On Sun, 29 Oct 2017 14:24:01 -0700 syzbot wrote: > syzkaller has found reproducer for the following crash on > 36ef71cae353f88fd6e095e2aaa3e5953af1685d So this fuzzer triggers this. >

Re: [RESEND v12 0/6] cgroup-aware OOM killer

On Tue, 31 Oct 2017, Michal Hocko wrote: > > I'm not ignoring them, I have stated that we need the ability to protect > > important cgroups on the system without oom disabling all attached > > processes. If that is implemented as a memory.oom_score_adj with the same > > semantics as

Re: WARNING in tracepoint_probe_register_prio

On Sun, 29 Oct 2017 14:24:01 -0700 syzbot wrote: > syzkaller has found reproducer for the following crash on > 36ef71cae353f88fd6e095e2aaa3e5953af1685d So this fuzzer triggers this. > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1

Re: [RESEND v12 0/6] cgroup-aware OOM killer

On Tue, 31 Oct 2017, Michal Hocko wrote: > > I'm not ignoring them, I have stated that we need the ability to protect > > important cgroups on the system without oom disabling all attached > > processes. If that is implemented as a memory.oom_score_adj with the same > > semantics as

[PATCH char-misc 1/1] Drivers: hv: vmbus: Implement Direct Mode for stimer0

From: Michael Kelley The 2016 version of Hyper-V offers the option to operate the guest VM per-vcpu stimer's in Direct Mode, which means the timer interupts on its own vector rather than queueing a VMbus message. Direct Mode reduces timer processing overhead in both the

[PATCH char-misc 1/1] Drivers: hv: vmbus: Implement Direct Mode for stimer0

From: Michael Kelley The 2016 version of Hyper-V offers the option to operate the guest VM per-vcpu stimer's in Direct Mode, which means the timer interupts on its own vector rather than queueing a VMbus message. Direct Mode reduces timer processing overhead in both the hypervisor and the

Re: [GIT PULL][PATCH 0/7] Timekeeping items for 4.15

On Mon, 30 Oct 2017, John Stultz wrote: > Hey Thomas, > Bit later then I'd like, but here's my current queue of > timekeeping items for 4.15. > > >From Arnd's patchset, I'm missing the last patch as it didn't > apply properly, but the rest of it looked ok to me. > > Please let me know if you

Re: [GIT PULL][PATCH 0/7] Timekeeping items for 4.15

On Mon, 30 Oct 2017, John Stultz wrote: > Hey Thomas, > Bit later then I'd like, but here's my current queue of > timekeeping items for 4.15. > > >From Arnd's patchset, I'm missing the last patch as it didn't > apply properly, but the rest of it looked ok to me. > > Please let me know if you

Re: [PATCH 04/17] coresight: Add generic TMC sg table framework

On Thu, Oct 19, 2017 at 06:15:40PM +0100, Suzuki K Poulose wrote: > This patch introduces a generic sg table data structure and > associated operations. An SG table can be used to map a set > of Data pages where the trace data could be stored by the TMC > ETR. The information about the data pages

Re: [PATCH 04/17] coresight: Add generic TMC sg table framework

On Thu, Oct 19, 2017 at 06:15:40PM +0100, Suzuki K Poulose wrote: > This patch introduces a generic sg table data structure and > associated operations. An SG table can be used to map a set > of Data pages where the trace data could be stored by the TMC > ETR. The information about the data pages

[RFC] xfs: fix reporting supported extra file attributes for statx()

statx(2) notes that any attribute that is not indicated as supported by stx_attributes_mask has no usable value. Commit 5f955f26f3d42d ("xfs: report crtime and attribute flags to statx") added support for informing userspace of extra file attributes but forgot to list these flags as supported

[RFC] xfs: fix reporting supported extra file attributes for statx()

statx(2) notes that any attribute that is not indicated as supported by stx_attributes_mask has no usable value. Commit 5f955f26f3d42d ("xfs: report crtime and attribute flags to statx") added support for informing userspace of extra file attributes but forgot to list these flags as supported

Re: [tip:core/urgent] futex: Fix more put_pi_state() vs. exit_pi_state_list() races

On Tue, 31 Oct 2017, tip-bot for Peter Zijlstra wrote: > Commit-ID: d5f6ac33189af48a0dc011190af5144947a30a76 > Gitweb: > https://git.kernel.org/tip/d5f6ac33189af48a0dc011190af5144947a30a76 > Author: Peter Zijlstra > AuthorDate: Tue, 31 Oct 2017 11:18:53 +0100 >

Re: [tip:core/urgent] futex: Fix more put_pi_state() vs. exit_pi_state_list() races

On Tue, 31 Oct 2017, tip-bot for Peter Zijlstra wrote: > Commit-ID: d5f6ac33189af48a0dc011190af5144947a30a76 > Gitweb: > https://git.kernel.org/tip/d5f6ac33189af48a0dc011190af5144947a30a76 > Author: Peter Zijlstra > AuthorDate: Tue, 31 Oct 2017 11:18:53 +0100 > Committer: Ingo Molnar

Re: Crashes in perf_event_ctx_lock_nested

On Tue, Oct 31, 2017 at 10:32:00PM +0100, Thomas Gleixner wrote: [ ...] > So we have to revert > > a33d44843d45 ("watchdog/hardlockup/perf: Simplify deferred event destroy") > > Patch attached. > Tested-by: Guenter Roeck There is still a problem. When running echo 6 >

Re: Crashes in perf_event_ctx_lock_nested

On Tue, Oct 31, 2017 at 10:32:00PM +0100, Thomas Gleixner wrote: [ ...] > So we have to revert > > a33d44843d45 ("watchdog/hardlockup/perf: Simplify deferred event destroy") > > Patch attached. > Tested-by: Guenter Roeck There is still a problem. When running echo 6 >

Re: [PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

On 10/31/2017 02:30 PM, Mark Salyzyn wrote: > Take an effort to recode the arm64 vdso code from assembler to C > previously submitted by Andrew Pinski , rework > it for use in both arm and arm64, overlapping any optimizations > for each architecture. But instead of landing it

Re: [PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

On 10/31/2017 02:30 PM, Mark Salyzyn wrote: > Take an effort to recode the arm64 vdso code from assembler to C > previously submitted by Andrew Pinski , rework > it for use in both arm and arm64, overlapping any optimizations > for each architecture. But instead of landing it in arm64, land the >

Re: [PATCH] MIPS: microMIPS: Fix incorrect mask in insn_table_MM

On Tue, Oct 31, 2017 at 07:08:04AM +, James Hogan wrote: > On Tue, Oct 31, 2017 at 12:35:03AM -0500, Gustavo A. R. Silva wrote: > > Signed-off-by: Gustavo A. R. Silva > > Reviewed-by: James Hogan That should of course be: Reviewed-by: James

Re: [PATCH] MIPS: microMIPS: Fix incorrect mask in insn_table_MM

On Tue, Oct 31, 2017 at 07:08:04AM +, James Hogan wrote: > On Tue, Oct 31, 2017 at 12:35:03AM -0500, Gustavo A. R. Silva wrote: > > Signed-off-by: Gustavo A. R. Silva > > Reviewed-by: James Hogan That should of course be: Reviewed-by: James Hogan

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On Mon, 30 Oct 2017 17:03:23 +0900 Masami Hiramatsu wrote: > > static LIST_HEAD(smp_alt_modules); > > -static DEFINE_MUTEX(smp_alt); > > -static bool uniproc_patched = false; /* protected by smp_alt */ > > +static bool uniproc_patched = false; /* protected by

[PATCH] storvsc: Avoid excessive host scan on controller change

From: Long Li When there are multiple disks attached to the same SCSI controller, the host may send several VSTOR_OPERATION_REMOVE_DEVICE or VSTOR_OPERATION_ENUMERATE_BUS messages in a row, to indicate there is a change on the SCSI controller. In response, storvsc rescans

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On Mon, 30 Oct 2017 17:03:23 +0900 Masami Hiramatsu wrote: > > static LIST_HEAD(smp_alt_modules); > > -static DEFINE_MUTEX(smp_alt); > > -static bool uniproc_patched = false; /* protected by smp_alt */ > > +static bool uniproc_patched = false; /* protected by text_mutex */ We

[PATCH] storvsc: Avoid excessive host scan on controller change

From: Long Li When there are multiple disks attached to the same SCSI controller, the host may send several VSTOR_OPERATION_REMOVE_DEVICE or VSTOR_OPERATION_ENUMERATE_BUS messages in a row, to indicate there is a change on the SCSI controller. In response, storvsc rescans the SCSI host. There

Re: [lkp-robot] [android/ion] 5fb70554d6: kernel_selftests.android.make_fail

On 10/31/2017 03:21 AM, Pintu Kumar wrote: > On Tue, Oct 31, 2017 at 2:32 AM, Laura Abbott wrote: >> On 10/30/2017 12:12 AM, Pintu Kumar wrote: >>> On Sun, Oct 29, 2017 at 7:51 PM, kernel test robot >>> wrote: FYI, we noticed the following

Re: [lkp-robot] [android/ion] 5fb70554d6: kernel_selftests.android.make_fail

On 10/31/2017 03:21 AM, Pintu Kumar wrote: > On Tue, Oct 31, 2017 at 2:32 AM, Laura Abbott wrote: >> On 10/30/2017 12:12 AM, Pintu Kumar wrote: >>> On Sun, Oct 29, 2017 at 7:51 PM, kernel test robot >>> wrote: FYI, we noticed the following commit (built with gcc-6): commit:

Excessive logging in thunderbolt driver

The thunderbolt driver needs to stop logging. All these debug messages and the laptop is on battery with no devices connected. (I did use a USB key, but that is not a thunderbolt device). IMHO a production driver should log nothing in normal operation. If you insist, the one message when device

Excessive logging in thunderbolt driver

The thunderbolt driver needs to stop logging. All these debug messages and the laptop is on battery with no devices connected. (I did use a USB key, but that is not a thunderbolt device). IMHO a production driver should log nothing in normal operation. If you insist, the one message when device

Re: [PATCH] scsi: ibmvscsi: Convert timers to use timer_setup()

On 10/25/2017 03:06 AM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: "Martin K. Petersen" >

Re: [PATCH] scsi: ibmvscsi: Convert timers to use timer_setup()

On 10/25/2017 03:06 AM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: "Martin K. Petersen" > Cc: Tyrel Datwyler > Cc:

Re: [PATCH 2/3] fpga: manager: don't use drvdata in common fpga code

On Tue, Oct 31, 2017 at 3:59 PM, Moritz Fischer wrote: > On Tue, Oct 31, 2017 at 08:42:14PM +, Alan Tull wrote: >> Changes to the fpga manager code to not use drvdata in common >> code. >> >> Change fpga_mgr_register to not set or use drvdata. >> >> Change the

Re: [PATCH 2/3] fpga: manager: don't use drvdata in common fpga code

On Tue, Oct 31, 2017 at 3:59 PM, Moritz Fischer wrote: > On Tue, Oct 31, 2017 at 08:42:14PM +, Alan Tull wrote: >> Changes to the fpga manager code to not use drvdata in common >> code. >> >> Change fpga_mgr_register to not set or use drvdata. >> >> Change the register/unregister function

Re: [PATCH] selftests/ftrace: Introduce exit_pass and exit_fail

On Tue, 31 Oct 2017 23:51:42 +0900 Masami Hiramatsu wrote: > diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/busy_check.tc > b/tools/testing/selftests/ftrace/test.d/kprobe/busy_check.tc > index 74507db8bbc8..b8701fa0b8f2 100644 > ---

[PATCH] PM / s2idle: Clear the events_check_enabled flag

Problem: This flag does not get cleared currently in the suspend or resume path in the following cases: * In case some driver's suspend routine returns an error. * Successful s2idle case * etc? Why is this a problem: What happens is that the next suspend attempt could fail even though the user

[PATCH] PM / s2idle: Clear the events_check_enabled flag

Problem: This flag does not get cleared currently in the suspend or resume path in the following cases: * In case some driver's suspend routine returns an error. * Successful s2idle case * etc? Why is this a problem: What happens is that the next suspend attempt could fail even though the user

Re: [PATCH] selftests/ftrace: Introduce exit_pass and exit_fail

On Tue, 31 Oct 2017 23:51:42 +0900 Masami Hiramatsu wrote: > diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/busy_check.tc > b/tools/testing/selftests/ftrace/test.d/kprobe/busy_check.tc > index 74507db8bbc8..b8701fa0b8f2 100644 > ---

Re: 67bb8e999e ("x86/mm: Disable various instrumentations of .."): BUG: -1 unexpected failures (out of 262) - debugging disabled! |

On Tue, Oct 31, 2017 at 10:09:44AM -0500, Tom Lendacky wrote: On 10/29/2017 8:39 PM, kernel test robot wrote: Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit

Re: 67bb8e999e ("x86/mm: Disable various instrumentations of .."): BUG: -1 unexpected failures (out of 262) - debugging disabled! |

On Tue, Oct 31, 2017 at 10:09:44AM -0500, Tom Lendacky wrote: On 10/29/2017 8:39 PM, kernel test robot wrote: Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit

[PATCH] scripts: warn about invalid MAINTAINERS patterns

Add "--pattern-checks" option to get_maintainer.pl to warn about invalid "F" and "X" patterns found in MAINTAINERS file(s). Signed-off-by: Tom Saeger Cc: Joe Perches --- scripts/get_maintainer.pl | 47 +++ 1

[PATCH] scripts: warn about invalid MAINTAINERS patterns

Add "--pattern-checks" option to get_maintainer.pl to warn about invalid "F" and "X" patterns found in MAINTAINERS file(s). Signed-off-by: Tom Saeger Cc: Joe Perches --- scripts/get_maintainer.pl | 47 +++ 1 file changed, 47 insertions(+) diff --git

Re: [PATCH v8 1/6] lib/dlock-list: Distributed and lock-protected lists

On Tue, 31 Oct 2017, Waiman Long wrote: +void dlock_lists_del(struct dlock_list_node *node) +{ + struct dlock_list_head *head; + bool retry; + + do { + head = READ_ONCE(node->head); Boqun had previously pointed this out; you need to WRITE_ONCE() node->head too.

Re: [PATCH v2 09/17] PCI: dwc: dra7xx: Add ifdefs for host/ep specific code

>>> >>> static int __init dra7xx_pcie_probe(struct platform_device *pdev) >>> { >>> @@ -681,6 +697,7 @@ static int __init dra7xx_pcie_probe(struct >>> platform_device *pdev) >>> dra7xx->link_gen = 2; >>> >>> switch (mode) { >>> +#ifdef CONFIG_PCI_DRA7XX_HOST >>> case

Re: [PATCH v8 1/6] lib/dlock-list: Distributed and lock-protected lists

On Tue, 31 Oct 2017, Waiman Long wrote: +void dlock_lists_del(struct dlock_list_node *node) +{ + struct dlock_list_head *head; + bool retry; + + do { + head = READ_ONCE(node->head); Boqun had previously pointed this out; you need to WRITE_ONCE() node->head too.

Re: [PATCH v2 09/17] PCI: dwc: dra7xx: Add ifdefs for host/ep specific code

>>> >>> static int __init dra7xx_pcie_probe(struct platform_device *pdev) >>> { >>> @@ -681,6 +697,7 @@ static int __init dra7xx_pcie_probe(struct >>> platform_device *pdev) >>> dra7xx->link_gen = 2; >>> >>> switch (mode) { >>> +#ifdef CONFIG_PCI_DRA7XX_HOST >>> case

Re: [PATCH v2 1/2] isofs: fix timestamps beyond 2027

On Tue, Oct 31, 2017 at 5:59 PM, Jan Kara wrote: > On Thu 19-10-17 17:29:12, Arnd Bergmann wrote: >> On Thu, Oct 19, 2017 at 5:17 PM, Jan Kara wrote: >> >> >> >> - year = p[0]; >> >> + year = (int)(u8)p[0]; >> > >> > The cast seems unnecessary now? >> > >> >>

Re: [PATCH v2 1/2] isofs: fix timestamps beyond 2027

On Tue, Oct 31, 2017 at 5:59 PM, Jan Kara wrote: > On Thu 19-10-17 17:29:12, Arnd Bergmann wrote: >> On Thu, Oct 19, 2017 at 5:17 PM, Jan Kara wrote: >> >> >> >> - year = p[0]; >> >> + year = (int)(u8)p[0]; >> > >> > The cast seems unnecessary now? >> > >> >> Sorry, I must have rebased

Re: [PATCH 4.4 00/20] 4.4.96-stable review

> On Oct 31, 2017, at 4:55 AM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.4.96 release. > There are 20 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being

Re: [PATCH 4.4 00/20] 4.4.96-stable review

> On Oct 31, 2017, at 4:55 AM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.4.96 release. > There are 20 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. >

Re: Crashes in perf_event_ctx_lock_nested

On Tue, 31 Oct 2017, Peter Zijlstra wrote: > On Mon, Oct 30, 2017 at 03:45:12PM -0700, Guenter Roeck wrote: > > I added some logging and a long msleep() in > > hardlockup_detector_perf_cleanup(). > > Here is the result: > > > > [0.274361] NMI watchdog:

Re: Crashes in perf_event_ctx_lock_nested

On Tue, 31 Oct 2017, Peter Zijlstra wrote: > On Mon, Oct 30, 2017 at 03:45:12PM -0700, Guenter Roeck wrote: > > I added some logging and a long msleep() in > > hardlockup_detector_perf_cleanup(). > > Here is the result: > > > > [0.274361] NMI watchdog:

Re: [PATCH v8 6/6] lib/dlock-list: Add an IRQ-safe mode to be used in interrupt handler

I would drop this patch for being too ugly and if nothing else, for lack of users (epoll will no longer need dlock). Thanks, Davidlohr

Re: [PATCH v8 6/6] lib/dlock-list: Add an IRQ-safe mode to be used in interrupt handler

I would drop this patch for being too ugly and if nothing else, for lack of users (epoll will no longer need dlock). Thanks, Davidlohr

[PATCH] selftests: vdso_test: support ARM64 targets

ARM64's vDSO exports its gettimeofday() implementation with a different name (__kernel_gettimeofday) and version (LINUX_2.6.39) from other architectures. Add a corresponding special-case to vdso_test. Signed-off-by: Greg Hackmann ---

[PATCH] selftests: vdso_test: support ARM64 targets

ARM64's vDSO exports its gettimeofday() implementation with a different name (__kernel_gettimeofday) and version (LINUX_2.6.39) from other architectures. Add a corresponding special-case to vdso_test. Signed-off-by: Greg Hackmann --- tools/testing/selftests/vDSO/vdso_test.c | 17

Nokia N9: fun with camera

Hi! Sakari, I am actually playing with N9 camera, not N950. That comes next. And the clock error I mentioned ... seems to be -EPROBE_DEFER. So... not an issue. Strange thing is, that my sensors seems to have different resolution from yours: - entity 89: smiapp pixel_array 1-0010 (1 pad, 1

Nokia N9: fun with camera

Hi! Sakari, I am actually playing with N9 camera, not N950. That comes next. And the clock error I mentioned ... seems to be -EPROBE_DEFER. So... not an issue. Strange thing is, that my sensors seems to have different resolution from yours: - entity 89: smiapp pixel_array 1-0010 (1 pad, 1

Re: [PATCH v2 09/17] PCI: dwc: dra7xx: Add ifdefs for host/ep specific code

On 10/31/2017 09:29 AM, Kishon Vijay Abraham I wrote: (snip) >> >> +#ifdef CONFIG_PCI_DRA7XX_HOST > > This block can also be moved around the file so that there is a single +#ifdef > CONFIG_PCI_DRA7XX_HOST in this file. Hello Kishon, Sure, will fix in V3. >> static int __init

Re: [PATCH v2 09/17] PCI: dwc: dra7xx: Add ifdefs for host/ep specific code

On 10/31/2017 09:29 AM, Kishon Vijay Abraham I wrote: (snip) >> >> +#ifdef CONFIG_PCI_DRA7XX_HOST > > This block can also be moved around the file so that there is a single +#ifdef > CONFIG_PCI_DRA7XX_HOST in this file. Hello Kishon, Sure, will fix in V3. >> static int __init

Re: Pull Request for linux-next

Hi Palmer, On Tue, 31 Oct 2017 13:43:26 -0700 (PDT) Palmer Dabbelt wrote: > > I'd like to request that you add the following tree to linux-next > > git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git > for-linux-next > > It contains the RISC-V port, which has

Re: Pull Request for linux-next

Hi Palmer, On Tue, 31 Oct 2017 13:43:26 -0700 (PDT) Palmer Dabbelt wrote: > > I'd like to request that you add the following tree to linux-next > > git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git > for-linux-next > > It contains the RISC-V port, which has been through 9

Re: [alsa-devel] [PATCH 08/14] soundwire: Add Slave status handling helpers

+ if (found == false) { + /* TODO: Park this device in Group 13 */ + dev_err(bus->dev, "Slave Entry not found"); No break here? Otherwise... Thats intentional. We want to still read next device that show up + } +

Re: [alsa-devel] [PATCH 08/14] soundwire: Add Slave status handling helpers

+ if (found == false) { + /* TODO: Park this device in Group 13 */ + dev_err(bus->dev, "Slave Entry not found"); No break here? Otherwise... Thats intentional. We want to still read next device that show up + } +

Re: [PATCH v2 06/17] PCI: designware-ep: Add generic function for raising MSI irq

On 10/31/2017 07:22 AM, Kishon Vijay Abraham I wrote: (snip) >> --- a/drivers/pci/dwc/pcie-designware.h >> +++ b/drivers/pci/dwc/pcie-designware.h >> @@ -106,6 +106,8 @@ >> #define MSI_CAP_MME_MASK(7 << MSI_CAP_MME_SHIFT) >> #define MSI_MESSAGE_ADDR_L320x54 >>

Re: [PATCH v2 06/17] PCI: designware-ep: Add generic function for raising MSI irq

On 10/31/2017 07:22 AM, Kishon Vijay Abraham I wrote: (snip) >> --- a/drivers/pci/dwc/pcie-designware.h >> +++ b/drivers/pci/dwc/pcie-designware.h >> @@ -106,6 +106,8 @@ >> #define MSI_CAP_MME_MASK(7 << MSI_CAP_MME_SHIFT) >> #define MSI_MESSAGE_ADDR_L320x54 >>

[PATCH RESEND] scsi: fnic: Clean up redundant variables

Remove variables that are set but not used. Signed-off-by: Christos Gkekas --- drivers/scsi/fnic/fnic_fcs.c | 9 - drivers/scsi/fnic/vnic_rq.c | 3 --- drivers/scsi/fnic/vnic_wq.c | 3 --- 3 files changed, 15 deletions(-) diff --git

[PATCH RESEND] scsi: fnic: Clean up redundant variables

Remove variables that are set but not used. Signed-off-by: Christos Gkekas --- drivers/scsi/fnic/fnic_fcs.c | 9 - drivers/scsi/fnic/vnic_rq.c | 3 --- drivers/scsi/fnic/vnic_wq.c | 3 --- 3 files changed, 15 deletions(-) diff --git a/drivers/scsi/fnic/fnic_fcs.c

Re: [PATCH 4.9 00/23] 4.9.60-stable review

> On Oct 31, 2017, at 4:55 AM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.9.60 release. > There are 23 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being

Re: [PATCH 4.9 00/23] 4.9.60-stable review

> On Oct 31, 2017, at 4:55 AM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.9.60 release. > There are 23 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. >

Re: [PATCH 2/3] fpga: manager: don't use drvdata in common fpga code

On Tue, Oct 31, 2017 at 08:42:14PM +, Alan Tull wrote: > Changes to the fpga manager code to not use drvdata in common > code. > > Change fpga_mgr_register to not set or use drvdata. > > Change the register/unregister function parameters to take the mgr > struct: > * int

Re: [PATCH 2/3] fpga: manager: don't use drvdata in common fpga code

On Tue, Oct 31, 2017 at 08:42:14PM +, Alan Tull wrote: > Changes to the fpga manager code to not use drvdata in common > code. > > Change fpga_mgr_register to not set or use drvdata. > > Change the register/unregister function parameters to take the mgr > struct: > * int

<    1   2   3   4   5   6   7   8   9   10   >