RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long

> -Original Message- > From: alexander.le...@verizon.com [mailto:alexander.le...@verizon.com] > Sent: Thursday, November 16, 2017 4:56 PM > To: Schmauss, Erik > Cc: Moore, Robert ; linux-kernel@vger.kernel.org; > sta...@vger.kernel.org;

[PATCH] watchdog: ib700wdt: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by: Gustavo A. R. Silva

[PATCH] watchdog: ib700wdt: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by: Gustavo A. R. Silva ---

RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long

> -Original Message- > From: alexander.le...@verizon.com [mailto:alexander.le...@verizon.com] > Sent: Thursday, November 16, 2017 4:56 PM > To: Schmauss, Erik > Cc: Moore, Robert ; linux-kernel@vger.kernel.org; > sta...@vger.kernel.org; Wysocki, Rafael J > Subject: RE: [PATCH AUTOSEL

Re: [PATCH 2/3] x86/apic: Update the 'apic=' description of setting APIC driver

On 11/20/2017 05:27 AM, Dou Liyang wrote: > There are two consumers of apic=: the APIC debug level and the low > level generic architecture code, but Linux just documented the first > one. > > Append the second description. > > Signed-off-by: Dou Liyang > --- >

Re: [PATCH 2/3] x86/apic: Update the 'apic=' description of setting APIC driver

On 11/20/2017 05:27 AM, Dou Liyang wrote: > There are two consumers of apic=: the APIC debug level and the low > level generic architecture code, but Linux just documented the first > one. > > Append the second description. > > Signed-off-by: Dou Liyang > --- >

Re: [PATCH 08/30] x86, kaiser: unmap kernel from userspace page tables (core patch)

On Fri, 10 Nov 2017, Dave Hansen wrote: > diff -puN arch/x86/entry/entry_64.S~kaiser-base arch/x86/entry/entry_64.S > --- a/arch/x86/entry/entry_64.S~kaiser-base 2017-11-10 11:22:09.007244950 > -0800 > +++ b/arch/x86/entry/entry_64.S 2017-11-10 11:22:09.031244950 -0800 > @@ -145,6 +145,16

Re: [PATCH 08/30] x86, kaiser: unmap kernel from userspace page tables (core patch)

On Fri, 10 Nov 2017, Dave Hansen wrote: > diff -puN arch/x86/entry/entry_64.S~kaiser-base arch/x86/entry/entry_64.S > --- a/arch/x86/entry/entry_64.S~kaiser-base 2017-11-10 11:22:09.007244950 > -0800 > +++ b/arch/x86/entry/entry_64.S 2017-11-10 11:22:09.031244950 -0800 > @@ -145,6 +145,16

Re: [GIT PULL] platform-drivers-x86 for 4.15-1

On Sat, Nov 18, 2017 at 12:09:10PM -0800, Linus Torvalds wrote: > On Sat, Nov 18, 2017 at 10:37 AM, Linus Torvalds > wrote: > > > > So I note that you seem to use the same summary script that Darren used. > > .. oh, and I note a *much* worse issue. > > You add new

Re: [GIT PULL] platform-drivers-x86 for 4.15-1

On Sat, Nov 18, 2017 at 12:09:10PM -0800, Linus Torvalds wrote: > On Sat, Nov 18, 2017 at 10:37 AM, Linus Torvalds > wrote: > > > > So I note that you seem to use the same summary script that Darren used. > > .. oh, and I note a *much* worse issue. > > You add new drivers and then default them

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On Fri, 17 Nov 2017 16:13:45 -0500 Tony Krowiak wrote: > On 11/16/2017 11:47 AM, Cornelia Huck wrote: > > [Also, is IOMMU_API only needed to satisfy dependencies?] > Yes, VFIO is dependent upon it. Ah, my question was more whether we just need to make sure the

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On Fri, 17 Nov 2017 16:13:45 -0500 Tony Krowiak wrote: > On 11/16/2017 11:47 AM, Cornelia Huck wrote: > > [Also, is IOMMU_API only needed to satisfy dependencies?] > Yes, VFIO is dependent upon it. Ah, my question was more whether we just need to make sure the api is there, but do not need

Re: [PATCH v4 3/9] arm64/acpi: Create arch specific cpu to acpi id helper

On Mon, Nov 20, 2017 at 11:09:47AM -0600, Jeremy Linton wrote: > Hi, > > On 11/20/2017 11:06 AM, Sudeep Holla wrote: > >On Thu, Nov 09, 2017 at 03:03:05PM -0600, Jeremy Linton wrote: > >>Its helpful to be able to lookup the acpi_processor_id > >>associated with a logical cpu. Provide an arm64 >

Re: [PATCH v4 3/9] arm64/acpi: Create arch specific cpu to acpi id helper

On Mon, Nov 20, 2017 at 11:09:47AM -0600, Jeremy Linton wrote: > Hi, > > On 11/20/2017 11:06 AM, Sudeep Holla wrote: > >On Thu, Nov 09, 2017 at 03:03:05PM -0600, Jeremy Linton wrote: > >>Its helpful to be able to lookup the acpi_processor_id > >>associated with a logical cpu. Provide an arm64 >

Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

On Fri, 17 Nov 2017 15:28:16 -0500 Tony Krowiak wrote: > On 11/17/2017 05:07 AM, Cornelia Huck wrote: > > On Fri, 17 Nov 2017 08:07:15 +0100 > > Pierre Morel wrote: > > > >> On 17/11/2017 00:35, Tony Krowiak wrote: > >>> On 11/16/2017

Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

On Fri, 17 Nov 2017 15:28:16 -0500 Tony Krowiak wrote: > On 11/17/2017 05:07 AM, Cornelia Huck wrote: > > On Fri, 17 Nov 2017 08:07:15 +0100 > > Pierre Morel wrote: > > > >> On 17/11/2017 00:35, Tony Krowiak wrote: > >>> On 11/16/2017 03:25 PM, Pierre Morel wrote: > On 16/11/2017

[PATCH 00/16] Entry stuff, in decent shape now

This sets up stack switching, including for SYSCALL. I think it's in decent shape. Known issues: - KASAN is likely to be busted. This could be fixed either by teaching KASAN that cpu_entry_area contains valid stacks (I have no clue how to go about doing this) or by rigging up the IST

[PATCH 00/16] Entry stuff, in decent shape now

This sets up stack switching, including for SYSCALL. I think it's in decent shape. Known issues: - KASAN is likely to be busted. This could be fixed either by teaching KASAN that cpu_entry_area contains valid stacks (I have no clue how to go about doing this) or by rigging up the IST

Re: [RFC PATCH v3 for 4.15 08/24] Provide cpu_opv system call

- On Nov 17, 2017, at 3:22 PM, Thomas Gleixner t...@linutronix.de wrote: > On Fri, 17 Nov 2017, Mathieu Desnoyers wrote: >> - On Nov 17, 2017, at 5:09 AM, Thomas Gleixner t...@linutronix.de wrote: >> 7) Allow libraries with multi-part algorithms to work on same per-cpu >>data without

Re: [RFC PATCH v3 for 4.15 08/24] Provide cpu_opv system call

- On Nov 17, 2017, at 3:22 PM, Thomas Gleixner t...@linutronix.de wrote: > On Fri, 17 Nov 2017, Mathieu Desnoyers wrote: >> - On Nov 17, 2017, at 5:09 AM, Thomas Gleixner t...@linutronix.de wrote: >> 7) Allow libraries with multi-part algorithms to work on same per-cpu >>data without

[PATCH 02/16] x86/dumpstack: Add get_stack_info() support for the SYSENTER stack

get_stack_info() doesn't currently know about the SYSENTER stack, so unwinding will fail if we entered the kernel on the SYSENTER stack and haven't fully switched off. Teach get_stack_info() about the SYSENTER stack. Signed-off-by: Andy Lutomirski ---

[PATCH 02/16] x86/dumpstack: Add get_stack_info() support for the SYSENTER stack

get_stack_info() doesn't currently know about the SYSENTER stack, so unwinding will fail if we entered the kernel on the SYSENTER stack and haven't fully switched off. Teach get_stack_info() about the SYSENTER stack. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/stacktrace.h | 3 +++

[PATCH 03/16] x86/gdt: Put per-cpu GDT remaps in ascending order

We currently have CPU 0's GDT at the top of the GDT range and higher-numbered CPUs at lower addreses. This happens because the fixmap is upside down (index 0 is the top of the fixmap). Flip it so that GDTs are in ascending order by virtual address. This will simplify a future patch that will

[PATCH 01/16] x86/asm/64: Allocate and enable the SYSENTER stack

This will simplify future changes that want scratch variables early in the SYSENTER handler -- they'll be able to spill registers to the stack. It also lets us get rid of a SWAPGS_UNSAFE_STACK user. This does not depend on CONFIG_IA32_EMULATION because we'll want the stack space even without

[PATCH 03/16] x86/gdt: Put per-cpu GDT remaps in ascending order

We currently have CPU 0's GDT at the top of the GDT range and higher-numbered CPUs at lower addreses. This happens because the fixmap is upside down (index 0 is the top of the fixmap). Flip it so that GDTs are in ascending order by virtual address. This will simplify a future patch that will

[PATCH 01/16] x86/asm/64: Allocate and enable the SYSENTER stack

This will simplify future changes that want scratch variables early in the SYSENTER handler -- they'll be able to spill registers to the stack. It also lets us get rid of a SWAPGS_UNSAFE_STACK user. This does not depend on CONFIG_IA32_EMULATION because we'll want the stack space even without

[PATCH 05/16] x86/asm: Fix assumptions that the HW TSS is at the beginning of cpu_tss

I'm going to move SYSENTER_stack to the beginning of cpu_tss to help detect overflow. Before this can happen, I need to fix several code paths that hardcode assumptions about the old layout. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/desc.h | 2 +-

[PATCH 05/16] x86/asm: Fix assumptions that the HW TSS is at the beginning of cpu_tss

I'm going to move SYSENTER_stack to the beginning of cpu_tss to help detect overflow. Before this can happen, I need to fix several code paths that hardcode assumptions about the old layout. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/desc.h | 2 +-

[PATCH 04/16] x86/fixmap: Generalize the GDT fixmap mechanism

Currently, the GDT is an ad-hoc array of pages, one per CPU, in the fixmap. Generalize it to be an array of a new struct cpu_entry_area so that we can cleanly add new things to it. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/desc.h | 9 +

[PATCH 07/16] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

I want SYSENTER_stack to have reliable overflow detection, which means that it needs to be at the bottom of a page, not the top. Move it to the beginning of struct tss_struct and page-align it. Also add an assertion to make sure that the fixed hardware TSS doesn't cross a page boundary.

[PATCH 04/16] x86/fixmap: Generalize the GDT fixmap mechanism

Currently, the GDT is an ad-hoc array of pages, one per CPU, in the fixmap. Generalize it to be an array of a new struct cpu_entry_area so that we can cleanly add new things to it. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/desc.h | 9 + arch/x86/include/asm/fixmap.h |

[PATCH 07/16] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

I want SYSENTER_stack to have reliable overflow detection, which means that it needs to be at the bottom of a page, not the top. Move it to the beginning of struct tss_struct and page-align it. Also add an assertion to make sure that the fixed hardware TSS doesn't cross a page boundary.

[PATCH 06/16] x86/dumpstack: Handle stack overflow on all stacks

We currently special-case stack overflow on the task stack. We're going to start putting special stacks in the fixmap with a custom layout, so they'll have guard pages, too. Teach the unwinder to be able to unwind an overflow of any of the stacks. Signed-off-by: Andy Lutomirski

[PATCH 06/16] x86/dumpstack: Handle stack overflow on all stacks

We currently special-case stack overflow on the task stack. We're going to start putting special stacks in the fixmap with a custom layout, so they'll have guard pages, too. Teach the unwinder to be able to unwind an overflow of any of the stacks. Signed-off-by: Andy Lutomirski ---

[PATCH 09/16] x86/asm/64: Separate cpu_current_top_of_stack from TSS.sp0

On 64-bit kernels, we used to assume that TSS.sp0 was the current top of stack. With the addition of an entry trampoline, this will no longer be the case. Store the current top of stack in TSS.sp1, which is otherwise unused but shares the same cacheline. Signed-off-by: Andy Lutomirski

[PATCH 09/16] x86/asm/64: Separate cpu_current_top_of_stack from TSS.sp0

On 64-bit kernels, we used to assume that TSS.sp0 was the current top of stack. With the addition of an entry trampoline, this will no longer be the case. Store the current top of stack in TSS.sp1, which is otherwise unused but shares the same cacheline. Signed-off-by: Andy Lutomirski ---

[PATCH 12/16] x86/asm/64: Return to userspace from the trampoline stack

By itself, this is useless. It gives us the ability to run some final code before exit that cannnot run on the kernel stack. This could include a CR3 switch a la KAISER or some kernel stack erasing, for example. (Or even weird things like *changing* which kernel stack gets used as an

[PATCH 12/16] x86/asm/64: Return to userspace from the trampoline stack

By itself, this is useless. It gives us the ability to run some final code before exit that cannnot run on the kernel stack. This could include a CR3 switch a la KAISER or some kernel stack erasing, for example. (Or even weird things like *changing* which kernel stack gets used as an

Re: [PATCH v4 3/9] arm64/acpi: Create arch specific cpu to acpi id helper

Hi, On 11/20/2017 11:06 AM, Sudeep Holla wrote: On Thu, Nov 09, 2017 at 03:03:05PM -0600, Jeremy Linton wrote: Its helpful to be able to lookup the acpi_processor_id associated with a logical cpu. Provide an arm64 helper to do this. Signed-off-by: Jeremy Linton ---

Re: [PATCH v4 3/9] arm64/acpi: Create arch specific cpu to acpi id helper

Hi, On 11/20/2017 11:06 AM, Sudeep Holla wrote: On Thu, Nov 09, 2017 at 03:03:05PM -0600, Jeremy Linton wrote: Its helpful to be able to lookup the acpi_processor_id associated with a logical cpu. Provide an arm64 helper to do this. Signed-off-by: Jeremy Linton ---

[PATCH 11/16] x86/asm/64: Use a percpu trampoline stack for IDT entries

Historically, IDT entries from usermode have always gone directly to the running task's kernel stack. Rearrange it so that we enter on a percpu trampoline stack and then manually switch to the task's stack. This touches a couple of extra cachelines, but it gives us a chance to run some code

[PATCH 11/16] x86/asm/64: Use a percpu trampoline stack for IDT entries

Historically, IDT entries from usermode have always gone directly to the running task's kernel stack. Rearrange it so that we enter on a percpu trampoline stack and then manually switch to the task's stack. This touches a couple of extra cachelines, but it gives us a chance to run some code

kernel build generates invalid object files on Ubuntu 13.10

I've just updated a linux source tree to the latest version (probably from Linus's public tree) and then tried to compile it (for x86_64) using gcc 4.7.3 and binutils 2.32.2 on a system running Ubuntu 13.10. While not the newest gcc, it isn't that old. The linker is reporting that some of the

[PATCH 14/16] x86/irq: Remove an old outdated comment about context tracking races

That race has been fixed and code cleaned up for a while now. --- arch/x86/kernel/irq.c | 12 1 file changed, 12 deletions(-) diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c index 49cfd9fe7589..68e1867cca80 100644 --- a/arch/x86/kernel/irq.c +++ b/arch/x86/kernel/irq.c @@

kernel build generates invalid object files on Ubuntu 13.10

I've just updated a linux source tree to the latest version (probably from Linus's public tree) and then tried to compile it (for x86_64) using gcc 4.7.3 and binutils 2.32.2 on a system running Ubuntu 13.10. While not the newest gcc, it isn't that old. The linker is reporting that some of the

[PATCH 14/16] x86/irq: Remove an old outdated comment about context tracking races

That race has been fixed and code cleaned up for a while now. --- arch/x86/kernel/irq.c | 12 1 file changed, 12 deletions(-) diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c index 49cfd9fe7589..68e1867cca80 100644 --- a/arch/x86/kernel/irq.c +++ b/arch/x86/kernel/irq.c @@

[PATCH 16/16] x86/entry/64: Move the IST stacks into cpu_entry_area

The IST stacks are needed when an IST exception occurs and are accessed before any kernel code at all runs. Move them into cpu_entry_area. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/fixmap.h | 10 ++ arch/x86/kernel/cpu/common.c | 40

[PATCH 16/16] x86/entry/64: Move the IST stacks into cpu_entry_area

The IST stacks are needed when an IST exception occurs and are accessed before any kernel code at all runs. Move them into cpu_entry_area. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/fixmap.h | 10 ++ arch/x86/kernel/cpu/common.c | 40

[PATCH 13/16] x86/entry/64: Create a percpu SYSCALL entry trampoline

Handling SYSCALL is tricky: the SYSCALL handler is entered with every single register (except FLAGS), including RSP, live. It somehow needs to set RSP to point to a valid stack, which means it needs to save the user RSP somewhere and find its own stack pointer. The canonical way to do this is

[PATCH 15/16] x86/irq/64: In the stack overflow warning, print the offending IP

In case something goes wrong with unwind (not unlikely in case of overflow), print the offending IP where we detected the overflow. --- arch/x86/kernel/irq_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/irq_64.c b/arch/x86/kernel/irq_64.c index

Re: [PATCH v2] dt-bindings: mtd: Add sst25vf016b to the list of supported chip names

Hi Geert, Le 20/11/2017 à 09:49, Geert Uytterhoeven a écrit : > Hi Cyrille, > > On Fri, Nov 17, 2017 at 6:36 PM, Cyrille Pitchen > wrote: >> sorry but I won't apply this patch. >> >> New values for the 'compatible' DT properties should only be added for >> memory

[PATCH 10/16] x86/espfix/64: Stop assuming that pt_regs is on the entry stack

When we start using an entry trampoline, a #GP from userspace will be delivered on the entry stack, not on the task stack. Fix the espfix64 #DF fixup to set up #GP according to TSS.SP0, rather than assuming that pt_regs + 1 == SP0. This won't change anything without an entry stack, but it will

[PATCH 13/16] x86/entry/64: Create a percpu SYSCALL entry trampoline

Handling SYSCALL is tricky: the SYSCALL handler is entered with every single register (except FLAGS), including RSP, live. It somehow needs to set RSP to point to a valid stack, which means it needs to save the user RSP somewhere and find its own stack pointer. The canonical way to do this is

[PATCH 15/16] x86/irq/64: In the stack overflow warning, print the offending IP

In case something goes wrong with unwind (not unlikely in case of overflow), print the offending IP where we detected the overflow. --- arch/x86/kernel/irq_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/irq_64.c b/arch/x86/kernel/irq_64.c index

Re: [PATCH v2] dt-bindings: mtd: Add sst25vf016b to the list of supported chip names

Hi Geert, Le 20/11/2017 à 09:49, Geert Uytterhoeven a écrit : > Hi Cyrille, > > On Fri, Nov 17, 2017 at 6:36 PM, Cyrille Pitchen > wrote: >> sorry but I won't apply this patch. >> >> New values for the 'compatible' DT properties should only be added for >> memory parts not supporting the JEDEC

[PATCH 10/16] x86/espfix/64: Stop assuming that pt_regs is on the entry stack

When we start using an entry trampoline, a #GP from userspace will be delivered on the entry stack, not on the task stack. Fix the espfix64 #DF fixup to set up #GP according to TSS.SP0, rather than assuming that pt_regs + 1 == SP0. This won't change anything without an entry stack, but it will

[PATCH 08/16] x86/asm: Remap the TSS into the cpu entry area

This has a secondary purpose: it puts the entry stack into a region with a well-controlled layout. A subsequent patch will take advantage of this to streamline the SYSCALL entry code to be able to find it more easily. Signed-off-by: Andy Lutomirski ---

[PATCH 08/16] x86/asm: Remap the TSS into the cpu entry area

This has a secondary purpose: it puts the entry stack into a region with a well-controlled layout. A subsequent patch will take advantage of this to streamline the SYSCALL entry code to be able to find it more easily. Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_32.S | 6 --

Re: [PATCH] ioctl_tty.2: add TIOCGPTPEER documentation

"Michael Kerrisk (man-pages)" writes: > On 08/16/2017 07:14 PM, Eric W. Biederman wrote: >> Aleksa Sarai writes: >> A couple of things to note on the bigger picture. The glibc library on all distributions has been changed to not have a

Re: [PATCH] ioctl_tty.2: add TIOCGPTPEER documentation

"Michael Kerrisk (man-pages)" writes: > On 08/16/2017 07:14 PM, Eric W. Biederman wrote: >> Aleksa Sarai writes: >> A couple of things to note on the bigger picture. The glibc library on all distributions has been changed to not have a setuid binary pt_chown, that uses

Re: [PATCH v4 3/9] arm64/acpi: Create arch specific cpu to acpi id helper

On Thu, Nov 09, 2017 at 03:03:05PM -0600, Jeremy Linton wrote: > Its helpful to be able to lookup the acpi_processor_id > associated with a logical cpu. Provide an arm64 > helper to do this. > > Signed-off-by: Jeremy Linton > --- > arch/arm64/include/asm/acpi.h | 4 >

[PATCH] watchdog: eurotechwdt: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by: Gustavo A. R. Silva

Re: [PATCH v4 3/9] arm64/acpi: Create arch specific cpu to acpi id helper

On Thu, Nov 09, 2017 at 03:03:05PM -0600, Jeremy Linton wrote: > Its helpful to be able to lookup the acpi_processor_id > associated with a logical cpu. Provide an arm64 > helper to do this. > > Signed-off-by: Jeremy Linton > --- > arch/arm64/include/asm/acpi.h | 4 > 1 file changed, 4

[PATCH] watchdog: eurotechwdt: mark expected switch fall-through

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by: Gustavo A. R. Silva ---

Re: [PATCH 1/1] mm/migrate: do not call prep_transhuge_page if !thp_migration_supported

Hi Yan Zi, thanks for the feedback. Yes, it looks definitely less redundant :) Regards, Andrea On Mon, Nov 20, 2017 at 11:33:06AM -0500, Zi Yan wrote: > Hi Andrea, > > Thanks for pointing this out. > > I think the problem is that we should not prep_transhuge_page(new_page) > unless new_page

Re: [PATCH 1/1] mm/migrate: do not call prep_transhuge_page if !thp_migration_supported

Hi Yan Zi, thanks for the feedback. Yes, it looks definitely less redundant :) Regards, Andrea On Mon, Nov 20, 2017 at 11:33:06AM -0500, Zi Yan wrote: > Hi Andrea, > > Thanks for pointing this out. > > I think the problem is that we should not prep_transhuge_page(new_page) > unless new_page

Re: [PATCH] ALSA: line6: add support for POD HD DESKTOP

On Mon, 20 Nov 2017 17:54:27 +0100, Hans Peter Möller wrote: > > Hi, since for Kernel 4.14 the source was changed for the timer issue, I > need to resend the patches to apply over 4.14 or it's no need for that? Don't worry, your change was already in Linus tree, included in 4.15-rc1. Takashi

Re: [PATCH] ALSA: line6: add support for POD HD DESKTOP

On Mon, 20 Nov 2017 17:54:27 +0100, Hans Peter Möller wrote: > > Hi, since for Kernel 4.14 the source was changed for the timer issue, I > need to resend the patches to apply over 4.14 or it's no need for that? Don't worry, your change was already in Linus tree, included in 4.15-rc1. Takashi

Re: Dell Vostro 3360 multimedia keys

Hi! On Monday 20 November 2017 16:08:41 Oleksandr Natalenko wrote: > Hi. > > I've got Dell Vostro 3360 with extra multimedia keys as shown here [1], but > have no luck to get them working. > > I've modified dell_wmi_smbios_list structure in drivers/platform/x86/dell- > wmi.c adding new entry:

Re: Dell Vostro 3360 multimedia keys

Hi! On Monday 20 November 2017 16:08:41 Oleksandr Natalenko wrote: > Hi. > > I've got Dell Vostro 3360 with extra multimedia keys as shown here [1], but > have no luck to get them working. > > I've modified dell_wmi_smbios_list structure in drivers/platform/x86/dell- > wmi.c adding new entry:

Re: [alsa-devel] [RFC PATCH 2/7] ASoC: Intel: Kconfig: Simplify-clarify ACPI/PCI dependencies

> I am aware that Edison could run with a modified 4.4 kernel, I just > don't know where the firmware is. I don't see anything for Merrifield in > /lib/firmware/intel? https://downloadmirror.intel.com/25028/eng/edison-image-from-src-package-ww25.5-15.zip I have no idea why it never made it

Re: [alsa-devel] [RFC PATCH 2/7] ASoC: Intel: Kconfig: Simplify-clarify ACPI/PCI dependencies

> I am aware that Edison could run with a modified 4.4 kernel, I just > don't know where the firmware is. I don't see anything for Merrifield in > /lib/firmware/intel? https://downloadmirror.intel.com/25028/eng/edison-image-from-src-package-ww25.5-15.zip I have no idea why it never made it

Re: [lkp-robot] [x86/mm] 9e52fc2b50: will-it-scale.per_thread_ops -16% regression

Vitaly Kuznetsov writes: > But adding such complexity to the code would require a good > justification, of course. Sorry for necroposting, I got distracted :-( I think I was able to reproduce the reported regression. The reproducer is dead simple, just several threads

Re: [lkp-robot] [x86/mm] 9e52fc2b50: will-it-scale.per_thread_ops -16% regression

Vitaly Kuznetsov writes: > But adding such complexity to the code would require a good > justification, of course. Sorry for necroposting, I got distracted :-( I think I was able to reproduce the reported regression. The reproducer is dead simple, just several threads doing

Re: [Patch v6 07/22] CIFS: SMBD: Implement function to create a SMB Direct connection

merged into cifs-2.6.git for-next On Sun, Nov 5, 2017 at 12:43 AM, Long Li wrote: > From: Long Li > > The upper layer calls this function to connect to peer through SMB Direct. > Each SMB Direct connection is based on a RDMA RC Queue Pair. >

Re: [Patch v6 07/22] CIFS: SMBD: Implement function to create a SMB Direct connection

merged into cifs-2.6.git for-next On Sun, Nov 5, 2017 at 12:43 AM, Long Li wrote: > From: Long Li > > The upper layer calls this function to connect to peer through SMB Direct. > Each SMB Direct connection is based on a RDMA RC Queue Pair. > > Signed-off-by: Long Li > --- >

Re: [Patch v7 06/22] CIFS: SMBD: export protocol initial values

merged into cifs-2.6.git for-next after cleaning up a couple checkpatch warnings On Mon, Nov 20, 2017 at 1:37 AM, Leif Sahlberg wrote: > Acked-by: Ronnie Sahlberg > > > - Original Message - > From: "Long Li" > To:

Re: [PATCH v2] binder: fix proc->files use-after-free

Al, thanks for the detailed feedback. I didn't know about these rules (are they written down somewhere?). I'll rework this and post a compliant v3. On Fri, Nov 17, 2017 at 11:31 AM, Al Viro wrote: > On Thu, Nov 16, 2017 at 09:56:50AM -0800, Todd Kjos wrote: > >> +static

Re: [Patch v7 06/22] CIFS: SMBD: export protocol initial values

merged into cifs-2.6.git for-next after cleaning up a couple checkpatch warnings On Mon, Nov 20, 2017 at 1:37 AM, Leif Sahlberg wrote: > Acked-by: Ronnie Sahlberg > > > - Original Message - > From: "Long Li" > To: "Steve French" , linux-c...@vger.kernel.org, >

Re: [PATCH v2] binder: fix proc->files use-after-free

Al, thanks for the detailed feedback. I didn't know about these rules (are they written down somewhere?). I'll rework this and post a compliant v3. On Fri, Nov 17, 2017 at 11:31 AM, Al Viro wrote: > On Thu, Nov 16, 2017 at 09:56:50AM -0800, Todd Kjos wrote: > >> +static struct files_struct

Re: [PATCH v4 5/9] drivers: base: cacheinfo: arm64: Add support for ACPI based firmware tables

On Thu, Nov 09, 2017 at 03:03:07PM -0600, Jeremy Linton wrote: > The /sys cache entries should support ACPI/PPTT generated cache > topology information. Lets detect ACPI systems and call > an arch specific cache_setup_acpi() routine to update the hardware > probed cache topology. > > For arm64,

Re: [PATCH v4 5/9] drivers: base: cacheinfo: arm64: Add support for ACPI based firmware tables

On Thu, Nov 09, 2017 at 03:03:07PM -0600, Jeremy Linton wrote: > The /sys cache entries should support ACPI/PPTT generated cache > topology information. Lets detect ACPI systems and call > an arch specific cache_setup_acpi() routine to update the hardware > probed cache topology. > > For arm64,

Re: [RFC] iio: light: acpi-als: Enable the light sensor on the Zenbook UX430UQ

On Sun, Nov 19, 2017 at 11:11 AM, Marek Vasut wrote: > On 11/19/2017 06:38 PM, Gabriele Mazzotta wrote: >> 2017-11-19 18:03 GMT+01:00 Jonathan Cameron : >>> On Wed, 15 Nov 2017 20:27:54 -0700 >>> Kiernan Hager wrote: >>> This makes

Re: [PATCH v2 06/15] ima: add parser of digest lists metadata

Quoting Mimi Zohar (zo...@linux.vnet.ibm.com): > On Mon, 2017-11-20 at 10:40 +0100, Roberto Sassu wrote: > > On 11/19/2017 12:23 AM, Mimi Zohar wrote: > > > Hi Serge, > > > > > > On Fri, 2017-11-17 at 22:20 -0600, Serge E. Hallyn wrote: > > >> On Tue, Nov 07, 2017 at 11:37:01AM +0100, Roberto

Re: [RFC] iio: light: acpi-als: Enable the light sensor on the Zenbook UX430UQ

On Sun, Nov 19, 2017 at 11:11 AM, Marek Vasut wrote: > On 11/19/2017 06:38 PM, Gabriele Mazzotta wrote: >> 2017-11-19 18:03 GMT+01:00 Jonathan Cameron : >>> On Wed, 15 Nov 2017 20:27:54 -0700 >>> Kiernan Hager wrote: >>> This makes acpi-als properly enable the light sensor on the Zenbook

Re: [PATCH v2 06/15] ima: add parser of digest lists metadata

Quoting Mimi Zohar (zo...@linux.vnet.ibm.com): > On Mon, 2017-11-20 at 10:40 +0100, Roberto Sassu wrote: > > On 11/19/2017 12:23 AM, Mimi Zohar wrote: > > > Hi Serge, > > > > > > On Fri, 2017-11-17 at 22:20 -0600, Serge E. Hallyn wrote: > > >> On Tue, Nov 07, 2017 at 11:37:01AM +0100, Roberto

Re: No check of the size passed to unmap_single in swiotlb

On 20/11/17 16:26, Konrad Rzeszutek Wilk wrote: On Mon, Nov 20, 2017 at 08:17:14AM +, Eric Yang wrote: Hi all, Hi! During debug a device only support 32bits DMA(Qualcomm Atheros AP) in our LS1043A 64bits ARM SOC, we found that the invoke of dma_unmap_single -->

Re: No check of the size passed to unmap_single in swiotlb

On 20/11/17 16:26, Konrad Rzeszutek Wilk wrote: On Mon, Nov 20, 2017 at 08:17:14AM +, Eric Yang wrote: Hi all, Hi! During debug a device only support 32bits DMA(Qualcomm Atheros AP) in our LS1043A 64bits ARM SOC, we found that the invoke of dma_unmap_single -->

Re: [PATCH 01/10 v4] Input: ep93xx_keypad: Fix platform_get_irq's error checking

On Mon, Nov 20, 2017 at 8:29 AM, Russell King - ARM Linux wrote: > On Mon, Nov 20, 2017 at 09:56:21PM +0530, Arvind Yadav wrote: >> The platform_get_irq() function returns negative if an error occurs. >> zero or positive number on success. platform_get_irq() error checking

Re: [LTP] Towards 4.14 LTS

> On Nov 20, 2017, at 10:10 AM, Cyril Hrubis wrote: > > Hi! >> So why didn???t we report these? As mentioned we???ve been tossing out dodgy >> test cases to get to a clean baseline. We don???t need or want noise. >> >> For LTS, I want the system when it detects a failure to

Re: [PATCH 01/10 v4] Input: ep93xx_keypad: Fix platform_get_irq's error checking

On Mon, Nov 20, 2017 at 8:29 AM, Russell King - ARM Linux wrote: > On Mon, Nov 20, 2017 at 09:56:21PM +0530, Arvind Yadav wrote: >> The platform_get_irq() function returns negative if an error occurs. >> zero or positive number on success. platform_get_irq() error checking >> for zero is not

Re: [LTP] Towards 4.14 LTS

> On Nov 20, 2017, at 10:10 AM, Cyril Hrubis wrote: > > Hi! >> So why didn???t we report these? As mentioned we???ve been tossing out dodgy >> test cases to get to a clean baseline. We don???t need or want noise. >> >> For LTS, I want the system when it detects a failure to enable a quick

Re: [PATCH 00/13] block: assorted cleanup for bio splitting and cloning.

On Sun, Jun 18, 2017 at 5:36 PM, NeilBrown wrote: > On Sun, Jun 18 2017, Jens Axboe wrote: > >> On Sun, Jun 18 2017, NeilBrown wrote: >>> This is a resend of my series of patches working >>> towards removing the bioset work queues. >>> >>> This set is based on for-4.13/block. >>>

Re: [PATCH 00/13] block: assorted cleanup for bio splitting and cloning.

On Sun, Jun 18, 2017 at 5:36 PM, NeilBrown wrote: > On Sun, Jun 18 2017, Jens Axboe wrote: > >> On Sun, Jun 18 2017, NeilBrown wrote: >>> This is a resend of my series of patches working >>> towards removing the bioset work queues. >>> >>> This set is based on for-4.13/block. >>> >>> It

Re: [PATCH][v4] uprobes/x86: emulate push insns for uprobe on x86

On 11/17, Yonghong Song wrote: > > On 11/17/17 9:25 AM, Oleg Nesterov wrote: > >On 11/15, Yonghong Song wrote: > >> > >>v3 -> v4: > >> . Revert most of v3 change as 32bit emulation is not really working > >> on x86_64 platform as among other issues, function emulate_push_stack() > >>

Re: [PATCH][v4] uprobes/x86: emulate push insns for uprobe on x86

On 11/17, Yonghong Song wrote: > > On 11/17/17 9:25 AM, Oleg Nesterov wrote: > >On 11/15, Yonghong Song wrote: > >> > >>v3 -> v4: > >> . Revert most of v3 change as 32bit emulation is not really working > >> on x86_64 platform as among other issues, function emulate_push_stack() > >>

Re: [PATCH] time: Make NTP optionnal

On Mon, 20 Nov 2017 17:29:53 +0100 Romain Perier wrote: > So even if the correspondong syscall are disabled and the > corresponding clocks too, you should return an -ENOSYS from the > do_adjtimex helper, in case that another component tries to use it in > the kernel,

Re: [PATCH] time: Make NTP optionnal

On Mon, 20 Nov 2017 17:29:53 +0100 Romain Perier wrote: > So even if the correspondong syscall are disabled and the > corresponding clocks too, you should return an -ENOSYS from the > do_adjtimex helper, in case that another component tries to use it in > the kernel, right ? Probably - but you

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

Ulf, On 11/20/17 06:44, Mark Rutland wrote: > On Sun, Nov 19, 2017 at 11:23:42PM -0500, Frank Rowand wrote: >> adding devicetree list, devicetree maintainers >> >> On 11/18/17 12:59, Ulf Samuelsson wrote: >>> I noticed when checking out the OpenWRT support for the board that they >>> have a

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

Ulf, On 11/20/17 06:44, Mark Rutland wrote: > On Sun, Nov 19, 2017 at 11:23:42PM -0500, Frank Rowand wrote: >> adding devicetree list, devicetree maintainers >> >> On 11/18/17 12:59, Ulf Samuelsson wrote: >>> I noticed when checking out the OpenWRT support for the board that they >>> have a

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