[patch V181 45/54] x86/mm: Use/Fix PCID to optimize user/kernel switches

2017-12-20 Thread Thomas Gleixner
From: Peter Zijlstra We can use PCID to retain the TLBs across CR3 switches; including those now part of the user/kernel switch. This increases performance of kernel entry/exit at the cost of more expensive/complicated TLB flushing. Now that we have two address spaces, one for kernel and one

[patch V181 30/54] x86/mm/pti: Allocate a separate user PGD

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen Kernel page table isolation requires to have two PGDs. One for the kernel, which contains the full kernel mapping plus the user space mapping and one for user space which contains the user space mappings and the minimal set of kernel mappings which are required by the

[patch V181 44/54] x86/mm: Abstract switching CR3

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen In preparation to adding additional PCID flushing, abstract the loading of a new ASID into CR3. [ PeterZ: Split out from big combo patch ] Signed-off-by: Dave Hansen Signed-off-by: Peter Zijlstra (Intel)

[patch V181 44/54] x86/mm: Abstract switching CR3

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen In preparation to adding additional PCID flushing, abstract the loading of a new ASID into CR3. [ PeterZ: Split out from big combo patch ] Signed-off-by: Dave Hansen Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Cc: Andy

[patch V181 29/54] x86/mm/pti: Allow NX poison to be set in p4d/pgd

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen With PAGE_TABLE_ISOLATION the user portion of the kernel page tables is poisoned with the NX bit so if the entry code exits with the kernel page tables selected in CR3, userspace crashes. But doing so trips the p4d/pgd_bad() checks. Make sure it

[patch V181 29/54] x86/mm/pti: Allow NX poison to be set in p4d/pgd

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen With PAGE_TABLE_ISOLATION the user portion of the kernel page tables is poisoned with the NX bit so if the entry code exits with the kernel page tables selected in CR3, userspace crashes. But doing so trips the p4d/pgd_bad() checks. Make sure it does not do that.

[patch V181 48/54] x86/mm: Clarify the whole ASID/kernel PCID/user PCID naming

2017-12-20 Thread Thomas Gleixner
From: Peter Zijlstra Ideally we'd also use sparse to enforce this separation so it becomes much more difficult to mess up. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

[patch V181 48/54] x86/mm: Clarify the whole ASID/kernel PCID/user PCID naming

2017-12-20 Thread Thomas Gleixner
From: Peter Zijlstra Ideally we'd also use sparse to enforce this separation so it becomes much more difficult to mess up. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian

[patch V181 51/54] x86/mm/dump_pagetables: Add page table directory

2017-12-20 Thread Thomas Gleixner
The upcoming support for dumping the kernel and the user space page tables of the current process would create more random files in the top level debugfs directory. Add a page table directory and move the existing file to it. Signed-off-by: Borislav Petkov Signed-off-by: Ingo

[patch V181 51/54] x86/mm/dump_pagetables: Add page table directory

2017-12-20 Thread Thomas Gleixner
The upcoming support for dumping the kernel and the user space page tables of the current process would create more random files in the top level debugfs directory. Add a page table directory and move the existing file to it. Signed-off-by: Borislav Petkov Signed-off-by: Ingo Molnar

[patch V181 28/54] x86/mm/pti: Add mapping helper functions

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen Add the pagetable helper functions do manage the separate user space page tables. [ tglx: Split out from the big combo kaiser patch. Folded Andys simplification and made it out of line as Boris suggested ] Signed-off-by: Dave Hansen

[patch V181 49/54] x86/dumpstack: Indicate in Oops whether pti is configured and enabled

2017-12-20 Thread Thomas Gleixner
From: Vlastimil Babka CONFIG_PAGE_TABLE_ISOLATION is relatively new and intrusive feature that may still have some corner cases which could take some time to manifest and be fixed. It would be useful to have Oops messages indicate whether it was enabled for building the kernel,

[patch V181 47/54] x86/mm: Use INVPCID for __native_flush_tlb_single()

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen This uses INVPCID to shoot down individual lines of the user mapping instead of marking the entire user map as invalid. This could/might/possibly be faster. This for sure needs tlb_single_page_flush_ceiling to be redetermined; esp. since INVPCID is

[patch V181 28/54] x86/mm/pti: Add mapping helper functions

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen Add the pagetable helper functions do manage the separate user space page tables. [ tglx: Split out from the big combo kaiser patch. Folded Andys simplification and made it out of line as Boris suggested ] Signed-off-by: Dave Hansen Signed-off-by: Thomas Gleixner

[patch V181 49/54] x86/dumpstack: Indicate in Oops whether pti is configured and enabled

2017-12-20 Thread Thomas Gleixner
From: Vlastimil Babka CONFIG_PAGE_TABLE_ISOLATION is relatively new and intrusive feature that may still have some corner cases which could take some time to manifest and be fixed. It would be useful to have Oops messages indicate whether it was enabled for building the kernel, and whether it

[patch V181 47/54] x86/mm: Use INVPCID for __native_flush_tlb_single()

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen This uses INVPCID to shoot down individual lines of the user mapping instead of marking the entire user map as invalid. This could/might/possibly be faster. This for sure needs tlb_single_page_flush_ceiling to be redetermined; esp. since INVPCID is _slow_. A detailed

[patch V181 34/54] x86/mm/pti: Share cpu_entry_area with user space page tables

2017-12-20 Thread Thomas Gleixner
From: Andy Lutomirski Share the cpu entry area so the user space and kernel space page tables have the same P4D page. Signed-off-by: Andy Lutomirski Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Cc: Boris

[patch V181 52/54] x86/mm/dump_pagetables: Check user space page table for WX pages

2017-12-20 Thread Thomas Gleixner
From: Thomas Gleixner ptdump_walk_pgd_level_checkwx() checks the kernel page table for WX pages, but does not check the PAGE_TABLE_ISOLATION user space page table. Restructure the code so that dmesg output is selected by an explicit argument and not implicit via checking the

[patch V181 34/54] x86/mm/pti: Share cpu_entry_area with user space page tables

2017-12-20 Thread Thomas Gleixner
From: Andy Lutomirski Share the cpu entry area so the user space and kernel space page tables have the same P4D page. Signed-off-by: Andy Lutomirski Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: David

[patch V181 52/54] x86/mm/dump_pagetables: Check user space page table for WX pages

2017-12-20 Thread Thomas Gleixner
From: Thomas Gleixner ptdump_walk_pgd_level_checkwx() checks the kernel page table for WX pages, but does not check the PAGE_TABLE_ISOLATION user space page table. Restructure the code so that dmesg output is selected by an explicit argument and not implicit via checking the pgd argument for

[patch V181 41/54] x86/pti: Put the LDT in its own PGD if PTI is on

2017-12-20 Thread Thomas Gleixner
From: Andy Lutomirski With PTI enabled, the LDT must be mapped in the usermode tables somewhere. The LDT is per process, i.e. per mm. An earlier approach mapped the LDT on context switch into a fixmap area, but that's a big overhead and exhausted the fixmap space when NR_CPUS

[patch V181 41/54] x86/pti: Put the LDT in its own PGD if PTI is on

2017-12-20 Thread Thomas Gleixner
From: Andy Lutomirski With PTI enabled, the LDT must be mapped in the usermode tables somewhere. The LDT is per process, i.e. per mm. An earlier approach mapped the LDT on context switch into a fixmap area, but that's a big overhead and exhausted the fixmap space when NR_CPUS got big. Take

[PATCH] proc: rearrange struct proc_dir_entry

2017-12-20 Thread Alexey Dobriyan
struct proc_dir_entry became bit messy over years: * move 16-bit ->mode_t before namelen to get rid of padding * make ->in_use first field: it seems to be most used resulting in smaller code on x86_64 (defconfig): add/remove: 0/0 grow/shrink: 7/13 up/down: 24/-67 (-43) Function

[PATCH] proc: rearrange struct proc_dir_entry

2017-12-20 Thread Alexey Dobriyan
struct proc_dir_entry became bit messy over years: * move 16-bit ->mode_t before namelen to get rid of padding * make ->in_use first field: it seems to be most used resulting in smaller code on x86_64 (defconfig): add/remove: 0/0 grow/shrink: 7/13 up/down: 24/-67 (-43) Function

[patch V181 50/54] x86/mm/pti: Add Kconfig

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen Finally allow CONFIG_PAGE_TABLE_ISOLATION to be enabled. 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

[patch V181 50/54] x86/mm/pti: Add Kconfig

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen Finally allow CONFIG_PAGE_TABLE_ISOLATION to be enabled. 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.

[patch V181 54/54] x86/ldt: Make the LDT mapping RO

2017-12-20 Thread Thomas Gleixner
From: Thomas Gleixner Now that the LDT mapping is in a known area when PAGE_TABLE_ISOLATION is enabled its a primary target for attacks, if a user space interface fails to validate a write address correctly. That can never happen, right? The SDM states: If the segment

[patch V181 54/54] x86/ldt: Make the LDT mapping RO

2017-12-20 Thread Thomas Gleixner
From: Thomas Gleixner Now that the LDT mapping is in a known area when PAGE_TABLE_ISOLATION is enabled its a primary target for attacks, if a user space interface fails to validate a write address correctly. That can never happen, right? The SDM states: If the segment descriptors in the

[patch V181 43/54] x86/mm: Allow flushing for future ASID switches

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen If changing the page tables in such a way that an invalidation of all contexts (aka. PCIDs / ASIDs) is required, they can be actively invalidated by: 1. INVPCID for each PCID (works for single pages too). 2. Load CR3 with each PCID without the

[patch V181 46/54] x86/mm: Optimize RESTORE_CR3

2017-12-20 Thread Thomas Gleixner
From: Peter Zijlstra Most NMI/paranoid exceptions will not in fact change pagetables and would thus not require TLB flushing, however RESTORE_CR3 uses flushing CR3 writes. Restores to kernel PCIDs can be NOFLUSH, because we explicitly flush the kernel mappings and now that

[patch V181 43/54] x86/mm: Allow flushing for future ASID switches

2017-12-20 Thread Thomas Gleixner
From: Dave Hansen If changing the page tables in such a way that an invalidation of all contexts (aka. PCIDs / ASIDs) is required, they can be actively invalidated 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

[patch V181 46/54] x86/mm: Optimize RESTORE_CR3

2017-12-20 Thread Thomas Gleixner
From: Peter Zijlstra Most NMI/paranoid exceptions will not in fact change pagetables and would thus not require TLB flushing, however RESTORE_CR3 uses flushing CR3 writes. Restores to kernel PCIDs can be NOFLUSH, because we explicitly flush the kernel mappings and now that we track which user

[patch V181 53/54] x86/mm/dump_pagetables: Allow dumping current pagetables

2017-12-20 Thread Thomas Gleixner
From: Thomas Gleixner Add two debugfs files which allow to dump the pagetable of the current task. current_kernel dumps the regular page table. This is the page table which is normally shared between kernel and user space. If kernel page table isolation is enabled this is

[patch V181 53/54] x86/mm/dump_pagetables: Allow dumping current pagetables

2017-12-20 Thread Thomas Gleixner
From: Thomas Gleixner Add two debugfs files which allow to dump the pagetable of the current task. current_kernel dumps the regular page table. This is the page table which is normally shared between kernel and user space. If kernel page table isolation is enabled this is the kernel space

[patch V181 20/54] x86/mm: Create asm/invpcid.h

2017-12-20 Thread Thomas Gleixner
From: Peter Zijlstra Unclutter tlbflush.h a little. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov

[patch V181 20/54] x86/mm: Create asm/invpcid.h

2017-12-20 Thread Thomas Gleixner
From: Peter Zijlstra Unclutter tlbflush.h a little. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: David Laight Cc: Denys Vlasenko Cc: Eduardo Valentin Cc: Greg KH Cc: H.

[patch V181 14/54] x86/mm: Use __flush_tlb_one() for kernel memory

2017-12-20 Thread Thomas Gleixner
From: Peter Zijlstra __flush_tlb_single() is for user mappings, __flush_tlb_one() for kernel mappings. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Cc: Andy

[patch V181 14/54] x86/mm: Use __flush_tlb_one() for kernel memory

2017-12-20 Thread Thomas Gleixner
From: Peter Zijlstra __flush_tlb_single() is for user mappings, __flush_tlb_one() for kernel mappings. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave

[patch V181 12/54] x86/uv: Use the right tlbflush API

2017-12-20 Thread Thomas Gleixner
From: Peter Zijlstra Since uv_flush_tlb_others() implements flush_tlb_others() which is about flushing user mappings, we should use __flush_tlb_single(), which too is about flushing user mappings. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by:

[patch V181 12/54] x86/uv: Use the right tlbflush API

2017-12-20 Thread Thomas Gleixner
From: Peter Zijlstra Since uv_flush_tlb_others() implements flush_tlb_others() which is about flushing user mappings, we should use __flush_tlb_single(), which too is about flushing user mappings. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

[patch V181 06/54] arch: Allow arch_dup_mmap() to fail

2017-12-20 Thread Thomas Gleixner
From: Thomas Gleixner In order to sanitize the LDT initialization on x86 arch_dup_mmap() must be allowed to fail. Fix up all instances. Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Cc: Juergen Gross

[patch V181 06/54] arch: Allow arch_dup_mmap() to fail

2017-12-20 Thread Thomas Gleixner
From: Thomas Gleixner In order to sanitize the LDT initialization on x86 arch_dup_mmap() must be allowed to fail. Fix up all instances. Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Cc: Juergen Gross Cc: Eduardo Valentin Cc: Denys Vlasenko Cc: aligu...@amazon.com Cc:

Re: [RFC PATCH net-next] tools/bpftool: use version from the kernel source tree

2017-12-20 Thread Jakub Kicinski
On Wed, 20 Dec 2017 20:53:41 +, Roman Gushchin wrote: > On Wed, Dec 20, 2017 at 12:29:21PM -0800, Jakub Kicinski wrote: > > On Wed, 20 Dec 2017 20:19:43 +, Roman Gushchin wrote: > > > Bpftool determines it's own version based on the kernel > > > version, which is picked from the

Re: [RFC PATCH net-next] tools/bpftool: use version from the kernel source tree

2017-12-20 Thread Jakub Kicinski
On Wed, 20 Dec 2017 20:53:41 +, Roman Gushchin wrote: > On Wed, Dec 20, 2017 at 12:29:21PM -0800, Jakub Kicinski wrote: > > On Wed, 20 Dec 2017 20:19:43 +, Roman Gushchin wrote: > > > Bpftool determines it's own version based on the kernel > > > version, which is picked from the

Re: [PATCH v16 0/5] ZII RAVE platform driver

2017-12-20 Thread Philippe Ombredanne
Andrey, On Wed, Dec 20, 2017 at 9:45 PM, Andrey Smirnov wrote: > Everyone: > > This patch series is v16 of the driver for supervisory processor found > on RAVE series of devices from ZII. Supervisory processor is a PIC > microcontroller connected to various electrical

Re: [PATCH v16 0/5] ZII RAVE platform driver

2017-12-20 Thread Philippe Ombredanne
Andrey, On Wed, Dec 20, 2017 at 9:45 PM, Andrey Smirnov wrote: > Everyone: > > This patch series is v16 of the driver for supervisory processor found > on RAVE series of devices from ZII. Supervisory processor is a PIC > microcontroller connected to various electrical subsystems on RAVE >

Re: [PATCH] clk: fix spin_lock/unlock imbalance on bad clk_enable() reentrancy

2017-12-20 Thread David Lechner
On 12/20/2017 02:33 PM, David Lechner wrote: So, as you can see, we get 4 warnings here. There is no problem with any clock provider or consumer (as far as I can tell). The bug here is that spin_trylock_irqsave() always returns true on non-SMP systems, which messes up the reference counting.

Re: [PATCH] clk: fix spin_lock/unlock imbalance on bad clk_enable() reentrancy

2017-12-20 Thread David Lechner
On 12/20/2017 02:33 PM, David Lechner wrote: So, as you can see, we get 4 warnings here. There is no problem with any clock provider or consumer (as far as I can tell). The bug here is that spin_trylock_irqsave() always returns true on non-SMP systems, which messes up the reference counting.

Re: [PATCH v2 1/2] dt-bindings: at24: new optional property - wp-gpios

2017-12-20 Thread Rob Herring
On Wed, Dec 20, 2017 at 09:26:32AM +0100, Bartosz Golaszewski wrote: > AT24 EEPROMs have a write-protect pin, which - when pulled high - > inhibits writes to the upper quadrant of memory (although it has been > observed that on some chips it disables writing to the entire memory > range). > > On

Re: [PATCH v2 1/2] dt-bindings: at24: new optional property - wp-gpios

2017-12-20 Thread Rob Herring
On Wed, Dec 20, 2017 at 09:26:32AM +0100, Bartosz Golaszewski wrote: > AT24 EEPROMs have a write-protect pin, which - when pulled high - > inhibits writes to the upper quadrant of memory (although it has been > observed that on some chips it disables writing to the entire memory > range). > > On

Re: [PATCH 0/2] platform/x86: silead_dmi: Add entries for 2 Chuwi tablets

2017-12-20 Thread Darren Hart
On Wed, Dec 20, 2017 at 11:30:07AM +0100, Hans de Goede wrote: > Hi Andy, et al, > > Here are 2 patches to add entries for 2 more Chuwi tablet models to > silead_dmi.c. Note that these are for 2 different tablets, even though > the entries look similar. > > I've based this series on top of the

Re: [PATCH 0/2] platform/x86: silead_dmi: Add entries for 2 Chuwi tablets

2017-12-20 Thread Darren Hart
On Wed, Dec 20, 2017 at 11:30:07AM +0100, Hans de Goede wrote: > Hi Andy, et al, > > Here are 2 patches to add entries for 2 more Chuwi tablet models to > silead_dmi.c. Note that these are for 2 different tablets, even though > the entries look similar. > > I've based this series on top of the

Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra

2017-12-20 Thread Jakub Jelinek
On Wed, Dec 20, 2017 at 09:52:05PM +0100, Arnd Bergmann wrote: > diff --git a/crypto/aes_generic.c b/crypto/aes_generic.c > index ca554d57d01e..35f973ba9878 100644 > --- a/crypto/aes_generic.c > +++ b/crypto/aes_generic.c > @@ -1331,6 +1331,20 @@ EXPORT_SYMBOL_GPL(crypto_aes_set_key); >

Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra

2017-12-20 Thread Jakub Jelinek
On Wed, Dec 20, 2017 at 09:52:05PM +0100, Arnd Bergmann wrote: > diff --git a/crypto/aes_generic.c b/crypto/aes_generic.c > index ca554d57d01e..35f973ba9878 100644 > --- a/crypto/aes_generic.c > +++ b/crypto/aes_generic.c > @@ -1331,6 +1331,20 @@ EXPORT_SYMBOL_GPL(crypto_aes_set_key); >

Re: [PATCH v3 02/20] dt-bindings: gpio: Add ASPEED constants

2017-12-20 Thread Rob Herring
On Wed, Dec 20, 2017 at 01:53:10PM +1030, Joel Stanley wrote: > These are used to by the device tree to map pin numbers to constants > required by the GPIO bindings. > > Signed-off-by: Joel Stanley > -- > v3: > - Remove dtsi includes from this patch, they will come later > --- >

Re: [PATCH v3 02/20] dt-bindings: gpio: Add ASPEED constants

2017-12-20 Thread Rob Herring
On Wed, Dec 20, 2017 at 01:53:10PM +1030, Joel Stanley wrote: > These are used to by the device tree to map pin numbers to constants > required by the GPIO bindings. > > Signed-off-by: Joel Stanley > -- > v3: > - Remove dtsi includes from this patch, they will come later > --- >

Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t

2017-12-20 Thread Rob Herring
On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu wrote: > Allwinner a83t has a 1 KB sid block with efuse for security rootkey and > thermal calibration data, add node to describe it. > > a83t-sid is not currently supported by nvmem/sunxi-sid, but it is > supported in an external driver

Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t

2017-12-20 Thread Rob Herring
On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu wrote: > Allwinner a83t has a 1 KB sid block with efuse for security rootkey and > thermal calibration data, add node to describe it. > > a83t-sid is not currently supported by nvmem/sunxi-sid, but it is > supported in an external driver

Re: [PATCH V2 4/4] perf/x86: fix: disable userspace RDPMC usage for large PEBS

2017-12-20 Thread Andi Kleen
On Wed, Dec 20, 2017 at 11:42:51AM -0800, kan.li...@linux.intel.com wrote: > From: Kan Liang > > The userspace RDPMC usage never works for large PEBS since the large > PEBS is introduced by > commit b8241d20699e ("perf/x86/intel: Implement batched PEBS interrupt >

Re: [PATCH V2 4/4] perf/x86: fix: disable userspace RDPMC usage for large PEBS

2017-12-20 Thread Andi Kleen
On Wed, Dec 20, 2017 at 11:42:51AM -0800, kan.li...@linux.intel.com wrote: > From: Kan Liang > > The userspace RDPMC usage never works for large PEBS since the large > PEBS is introduced by > commit b8241d20699e ("perf/x86/intel: Implement batched PEBS interrupt > handling (large PEBS interrupt

Re: [PATCH net-next 1/2] virtio_net: allow hypervisor to indicate linkspeed and duplex setting

2017-12-20 Thread Jason Baron
On 12/20/2017 12:52 PM, Michael S. Tsirkin wrote: > On Wed, Dec 20, 2017 at 12:07:55PM -0500, Jason Baron wrote: >> >> >> On 12/20/2017 09:57 AM, Michael S. Tsirkin wrote: >>> On Thu, Dec 14, 2017 at 02:33:53PM -0500, Jason Baron wrote: If the hypervisor exports the link and duplex speed,

Re: [PATCH net-next 1/2] virtio_net: allow hypervisor to indicate linkspeed and duplex setting

2017-12-20 Thread Jason Baron
On 12/20/2017 12:52 PM, Michael S. Tsirkin wrote: > On Wed, Dec 20, 2017 at 12:07:55PM -0500, Jason Baron wrote: >> >> >> On 12/20/2017 09:57 AM, Michael S. Tsirkin wrote: >>> On Thu, Dec 14, 2017 at 02:33:53PM -0500, Jason Baron wrote: If the hypervisor exports the link and duplex speed,

Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra

2017-12-20 Thread Arnd Bergmann
On Wed, Dec 20, 2017 at 10:14 PM, Ard Biesheuvel wrote: > On 20 December 2017 at 20:52, Arnd Bergmann wrote: > > You can use the tcrypt.ko module to benchmark AES. > > modprobe tcrypt mode=200 sec=1 Ok, that's what I was looking for. I don't think I'll

Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra

2017-12-20 Thread Arnd Bergmann
On Wed, Dec 20, 2017 at 10:14 PM, Ard Biesheuvel wrote: > On 20 December 2017 at 20:52, Arnd Bergmann wrote: > > You can use the tcrypt.ko module to benchmark AES. > > modprobe tcrypt mode=200 sec=1 Ok, that's what I was looking for. I don't think I'll have time to analyze this before my

Re: [PATCH v5 3/6] perf: implement pmu perf_kprobe

2017-12-20 Thread Peter Zijlstra
On Wed, Dec 20, 2017 at 06:10:11PM +, Song Liu wrote: > I think there is one more thing to change: OK, folded that too; it should all be at: git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core Can you verify it all looks/works right?

Re: [PATCH v5 3/6] perf: implement pmu perf_kprobe

2017-12-20 Thread Peter Zijlstra
On Wed, Dec 20, 2017 at 06:10:11PM +, Song Liu wrote: > I think there is one more thing to change: OK, folded that too; it should all be at: git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core Can you verify it all looks/works right?

Re: [PATCH v4 0/4] rtc: add mxc driver for i.MX53 SRTC

2017-12-20 Thread Alexandre Belloni
On 18/12/2017 at 12:51:29 +0100, linux-kernel-...@beckhoff.com wrote: > From: Patrick Bruenn > > Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53. > > This is driver enables support for the low power domain SRTC features: > - 32-bit MSB of non-rollover

Re: [PATCH v4 0/4] rtc: add mxc driver for i.MX53 SRTC

2017-12-20 Thread Alexandre Belloni
On 18/12/2017 at 12:51:29 +0100, linux-kernel-...@beckhoff.com wrote: > From: Patrick Bruenn > > Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53. > > This is driver enables support for the low power domain SRTC features: > - 32-bit MSB of non-rollover time counter > - 32-bit

Re: [PATCH v2 2/9] dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation

2017-12-20 Thread Rob Herring
On Tue, Dec 19, 2017 at 11:22:40AM -0800, Florian Fainelli wrote: > Correct the Device Tree bindings for the HIF_CPUBIUCTRL node whose > compatible string is actually brcm,bcm-cpu-biu-ctrl. Also > document in the binding the fallback property > ("brcm,brcmstb-cpu-biu-ctrl") and update the example

Re: [PATCH v2 2/9] dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation

2017-12-20 Thread Rob Herring
On Tue, Dec 19, 2017 at 11:22:40AM -0800, Florian Fainelli wrote: > Correct the Device Tree bindings for the HIF_CPUBIUCTRL node whose > compatible string is actually brcm,bcm-cpu-biu-ctrl. Also > document in the binding the fallback property > ("brcm,brcmstb-cpu-biu-ctrl") and update the example

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

2017-12-20 Thread Ross Zwisler
On Wed, Dec 20, 2017 at 01:16:49PM -0800, Matthew Wilcox wrote: > On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote: > > On 12/20/2017 10:19 AM, Matthew Wilcox wrote: > > > I don't know what the right interface is, but my laptop has a set of > > > /sys/devices/system/memory/memoryN/

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

2017-12-20 Thread Ross Zwisler
On Wed, Dec 20, 2017 at 01:16:49PM -0800, Matthew Wilcox wrote: > On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote: > > On 12/20/2017 10:19 AM, Matthew Wilcox wrote: > > > I don't know what the right interface is, but my laptop has a set of > > > /sys/devices/system/memory/memoryN/

Re: [PATCH] NFS: allow name_to_handle_at() to work for Amazon EFS.

2017-12-20 Thread NeilBrown
On Tue, Dec 19 2017, Jan Kara wrote: > On Fri 08-12-17 13:17:31, NeilBrown wrote: >> On Thu, Dec 07 2017, Amir Goldstein wrote: >> >> > On Thu, Dec 7, 2017 at 5:20 AM, NeilBrown wrote: >> >> On Wed, Dec 06 2017, Linus Torvalds wrote: >> >> >> >>> On Thu, Nov 30, 2017 at 12:56

Re: [PATCH] NFS: allow name_to_handle_at() to work for Amazon EFS.

2017-12-20 Thread NeilBrown
On Tue, Dec 19 2017, Jan Kara wrote: > On Fri 08-12-17 13:17:31, NeilBrown wrote: >> On Thu, Dec 07 2017, Amir Goldstein wrote: >> >> > On Thu, Dec 7, 2017 at 5:20 AM, NeilBrown wrote: >> >> On Wed, Dec 06 2017, Linus Torvalds wrote: >> >> >> >>> On Thu, Nov 30, 2017 at 12:56 PM, NeilBrown

Re: ps3: Improve a size determination in five functions

2017-12-20 Thread SF Markus Elfring
> Some observations: > > o Your patch fixes no bug nor replaces any depreciated feature. How do you think about information from the section “14) Allocating memory” in the document “coding-style.rst” for the shown source code transformation? > o There will be no functional change; … Yes. -

Re: ps3: Improve a size determination in five functions

2017-12-20 Thread SF Markus Elfring
> Some observations: > > o Your patch fixes no bug nor replaces any depreciated feature. How do you think about information from the section “14) Allocating memory” in the document “coding-style.rst” for the shown source code transformation? > o There will be no functional change; … Yes. -

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

2017-12-20 Thread Rob Herring
On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote: > Hi Viresh, > > On 12/20/2017 8:56 AM, Viresh Kumar wrote: > > On 19-12-17, 21:25, Sricharan R wrote: > >> + cpu@0 { > >> + compatible = "qcom,krait"; > >> + enable-method = "qcom,kpss-acc-v1"; > >> +

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

2017-12-20 Thread Rob Herring
On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote: > Hi Viresh, > > On 12/20/2017 8:56 AM, Viresh Kumar wrote: > > On 19-12-17, 21:25, Sricharan R wrote: > >> + cpu@0 { > >> + compatible = "qcom,krait"; > >> + enable-method = "qcom,kpss-acc-v1"; > >> +

Re: [PATCH 2/3] KVM: vmx: simplify MSR bitmap setup

2017-12-20 Thread Paolo Bonzini
On 20/12/2017 20:40, Jim Mattson wrote: > This doesn't look right to me. Without APIC-register virtualization, > the only X2APIC MSR intercept that should be disabled is TPR. Of course... The bitmap that has to be outside the "if" is *_x2apic_apicv, not *_x2apic. I sent the wrong version of the

Re: [PATCH 2/3] KVM: vmx: simplify MSR bitmap setup

2017-12-20 Thread Paolo Bonzini
On 20/12/2017 20:40, Jim Mattson wrote: > This doesn't look right to me. Without APIC-register virtualization, > the only X2APIC MSR intercept that should be disabled is TPR. Of course... The bitmap that has to be outside the "if" is *_x2apic_apicv, not *_x2apic. I sent the wrong version of the

Re: [PATCH 1/2] padata: Remove FSF address

2017-12-20 Thread Cheah Kok Cheong
On Wed, Dec 20, 2017 at 09:20:48PM +0100, Philippe Ombredanne wrote: > On Wed, Dec 20, 2017 at 9:15 PM, Cheah Kok Cheong wrote: > > Remove FSF address otherwise checkpatch will flag my next patch. > > > > Signed-off-by: Cheah Kok Cheong > > --- > >

Re: [PATCH 1/2] padata: Remove FSF address

2017-12-20 Thread Cheah Kok Cheong
On Wed, Dec 20, 2017 at 09:20:48PM +0100, Philippe Ombredanne wrote: > On Wed, Dec 20, 2017 at 9:15 PM, Cheah Kok Cheong wrote: > > Remove FSF address otherwise checkpatch will flag my next patch. > > > > Signed-off-by: Cheah Kok Cheong > > --- > > kernel/padata.c | 4 > > 1 file changed,

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

2017-12-20 Thread Matthew Wilcox
On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote: > On 12/20/2017 10:19 AM, Matthew Wilcox wrote: > > I don't know what the right interface is, but my laptop has a set of > > /sys/devices/system/memory/memoryN/ directories. Perhaps this is the > > right place to expose write_bw (etc).

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

2017-12-20 Thread Matthew Wilcox
On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote: > On 12/20/2017 10:19 AM, Matthew Wilcox wrote: > > I don't know what the right interface is, but my laptop has a set of > > /sys/devices/system/memory/memoryN/ directories. Perhaps this is the > > right place to expose write_bw (etc).

Re: [PATCH v5 12/15] devicetree: bindings: Document qcom,krait-cc

2017-12-20 Thread Rob Herring
On Tue, Dec 19, 2017 at 09:24:57PM +0530, Sricharan R wrote: > From: Stephen Boyd > > The Krait clock controller controls the krait CPU and the L2 clocks > consisting a primary mux and secondary mux. Add document for that. > > Signed-off-by: Stephen Boyd

Re: [PATCH v5 12/15] devicetree: bindings: Document qcom,krait-cc

2017-12-20 Thread Rob Herring
On Tue, Dec 19, 2017 at 09:24:57PM +0530, Sricharan R wrote: > From: Stephen Boyd > > The Krait clock controller controls the krait CPU and the L2 clocks > consisting a primary mux and secondary mux. Add document for that. > > Signed-off-by: Stephen Boyd > --- >

Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra

2017-12-20 Thread Ard Biesheuvel
On 20 December 2017 at 20:52, Arnd Bergmann wrote: > While testing other changes, I discovered that gcc-7.2.1 produces badly > optimized code for aes_encrypt/aes_decrypt. This is especially true when > CONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely > large stack

Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra

2017-12-20 Thread Ard Biesheuvel
On 20 December 2017 at 20:52, Arnd Bergmann wrote: > While testing other changes, I discovered that gcc-7.2.1 produces badly > optimized code for aes_encrypt/aes_decrypt. This is especially true when > CONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely > large stack usage that in

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

2017-12-20 Thread Ross Zwisler
On Wed, Dec 20, 2017 at 10:19:37AM -0800, Matthew Wilcox wrote: > On Mon, Dec 18, 2017 at 01:35:47PM -0700, Ross Zwisler wrote: > > What I'm hoping to do with this series is to just provide a sysfs > > representation of the HMAT so that applications can know which NUMA nodes to > > select with

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

2017-12-20 Thread Ross Zwisler
On Wed, Dec 20, 2017 at 10:19:37AM -0800, Matthew Wilcox wrote: > On Mon, Dec 18, 2017 at 01:35:47PM -0700, Ross Zwisler wrote: > > What I'm hoping to do with this series is to just provide a sysfs > > representation of the HMAT so that applications can know which NUMA nodes to > > select with

Re: [PATCH v5 10/15] devicetree: bindings: Document qcom,kpss-gcc

2017-12-20 Thread Rob Herring
On Tue, Dec 19, 2017 at 09:24:55PM +0530, Sricharan R wrote: > From: Stephen Boyd > > The ACC and GCC regions present in KPSSv1 contain registers to > control clocks and power to each Krait CPU and L2. Documenting > the bindings here. > > Signed-off-by: Stephen Boyd

Re: [PATCH v5 10/15] devicetree: bindings: Document qcom,kpss-gcc

2017-12-20 Thread Rob Herring
On Tue, Dec 19, 2017 at 09:24:55PM +0530, Sricharan R wrote: > From: Stephen Boyd > > The ACC and GCC regions present in KPSSv1 contain registers to > control clocks and power to each Krait CPU and L2. Documenting > the bindings here. > > Signed-off-by: Stephen Boyd > --- >

Re: [PATCH v5 05/15] devicetree: bindings: Document qcom,hfpll

2017-12-20 Thread Rob Herring
On Tue, Dec 19, 2017 at 09:24:50PM +0530, Sricharan R wrote: > From: Stephen Boyd > > Adds bindings document for qcom,hfpll instantiated within > the Krait processor subsystem as separate register region. > > Signed-off-by: Stephen Boyd > --- >

Re: [PATCH v5 05/15] devicetree: bindings: Document qcom,hfpll

2017-12-20 Thread Rob Herring
On Tue, Dec 19, 2017 at 09:24:50PM +0530, Sricharan R wrote: > From: Stephen Boyd > > Adds bindings document for qcom,hfpll instantiated within > the Krait processor subsystem as separate register region. > > Signed-off-by: Stephen Boyd > --- > .../devicetree/bindings/clock/qcom,hfpll.txt

Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

2017-12-20 Thread Megha Dey
On Wed, 2017-12-13 at 08:21 +0100, Peter Zijlstra wrote: > On Tue, Dec 12, 2017 at 03:08:00PM -0800, Megha Dey wrote: > > > > > > There's work on the way to allow multiple HW PMUs. You'll either have to > > > wait for that or help in making that happen. What you do not do is > > > silently hack

Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

2017-12-20 Thread Megha Dey
On Wed, 2017-12-13 at 08:21 +0100, Peter Zijlstra wrote: > On Tue, Dec 12, 2017 at 03:08:00PM -0800, Megha Dey wrote: > > > > > > There's work on the way to allow multiple HW PMUs. You'll either have to > > > wait for that or help in making that happen. What you do not do is > > > silently hack

Re: [PATCH v3 2/5] drm/tegra: Restore opaque and drop alpha formats on Tegra20/30

2017-12-20 Thread Dmitry Osipenko
On 20.12.2017 23:16, Thierry Reding wrote: > On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote: >> On 20.12.2017 21:01, Thierry Reding wrote: >>> On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote: Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")

Re: [PATCH v3 2/5] drm/tegra: Restore opaque and drop alpha formats on Tegra20/30

2017-12-20 Thread Dmitry Osipenko
On 20.12.2017 23:16, Thierry Reding wrote: > On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote: >> On 20.12.2017 21:01, Thierry Reding wrote: >>> On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote: Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")

[PATCH] checkpatch: Add a few DEVICE_ATTR style tests

2017-12-20 Thread Joe Perches
DEVICE_ATTR is a declaration macro that has a few alternate and preferred forms like DEVICE_ATTR_RW, DEVICE_ATTR_RO, and DEVICE_ATTR. As well, many uses of DEVICE_ATTR could use the preferred forms when the show or store functions are also named in a regular form. Suggest the preferred forms

[PATCH] checkpatch: Add a few DEVICE_ATTR style tests

2017-12-20 Thread Joe Perches
DEVICE_ATTR is a declaration macro that has a few alternate and preferred forms like DEVICE_ATTR_RW, DEVICE_ATTR_RO, and DEVICE_ATTR. As well, many uses of DEVICE_ATTR could use the preferred forms when the show or store functions are also named in a regular form. Suggest the preferred forms

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