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

Kirill A. Shutemov wrote: > Something like this? > > > From 251e124630da82482e8b320c73162ce89af04d5d Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" > Date: Thu, 18 Jan 2018 18:24:07 +0300 > Subject: [PATCH] mm, page_vma_mapped: Fix pointer arithmetics in

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

Kirill A. Shutemov wrote: > Something like this? > > > From 251e124630da82482e8b320c73162ce89af04d5d Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" > Date: Thu, 18 Jan 2018 18:24:07 +0300 > Subject: [PATCH] mm, page_vma_mapped: Fix pointer arithmetics in check_pte() > > Tetsuo reported

[PATCH v10 10/27] powerpc: store and restore the pkey state across context switches

Store and restore the AMR, IAMR and UAMOR register state of the task before scheduling out and after scheduling in, respectively. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu_context.h |3 ++ arch/powerpc/include/asm/pkeys.h |4 ++

[PATCH v10 10/27] powerpc: store and restore the pkey state across context switches

Store and restore the AMR, IAMR and UAMOR register state of the task before scheduling out and after scheduling in, respectively. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu_context.h |3 ++ arch/powerpc/include/asm/pkeys.h |4 ++ arch/powerpc/include/asm/processor.h

[PATCH] drm: Check for lessee in DROP_MASTER ioctl

Don't let a lessee control what the current DRM master is set to; that's the job of the "real" master. Otherwise, the lessee would disable all access to master operations for the owner and all lessees under it. This matches the same check made in the SET_MASTER ioctl. Signed-off-by: Keith

[PATCH] drm: Check for lessee in DROP_MASTER ioctl

Don't let a lessee control what the current DRM master is set to; that's the job of the "real" master. Otherwise, the lessee would disable all access to master operations for the owner and all lessees under it. This matches the same check made in the SET_MASTER ioctl. Signed-off-by: Keith

[PATCH v10 11/27] powerpc: introduce execute-only pkey

This patch provides the implementation of execute-only pkey. The architecture-independent layer expects the arch-dependent layer, to support the ability to create and enable a special key which has execute-only permission. Acked-by: Balbir Singh Signed-off-by: Ram Pai

[PATCH v10 11/27] powerpc: introduce execute-only pkey

This patch provides the implementation of execute-only pkey. The architecture-independent layer expects the arch-dependent layer, to support the ability to create and enable a special key which has execute-only permission. Acked-by: Balbir Singh Signed-off-by: Ram Pai ---

[PATCH v10 12/27] powerpc: ability to associate pkey to a vma

arch-independent code expects the arch to map a pkey into the vma's protection bit setting. The patch provides that ability. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mman.h |7 ++- arch/powerpc/include/asm/pkeys.h | 11 +++

[PATCH v10 13/27] powerpc: implementation for arch_override_mprotect_pkey()

arch independent code calls arch_override_mprotect_pkey() to return a pkey that best matches the requested protection. This patch provides the implementation. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu_context.h |5 arch/powerpc/include/asm/pkeys.h

[PATCH v10 13/27] powerpc: implementation for arch_override_mprotect_pkey()

arch independent code calls arch_override_mprotect_pkey() to return a pkey that best matches the requested protection. This patch provides the implementation. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu_context.h |5 arch/powerpc/include/asm/pkeys.h | 21

[PATCH v10 12/27] powerpc: ability to associate pkey to a vma

arch-independent code expects the arch to map a pkey into the vma's protection bit setting. The patch provides that ability. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mman.h |7 ++- arch/powerpc/include/asm/pkeys.h | 11 +++ arch/powerpc/mm/pkeys.c |

[PATCH v10 01/27] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS is enabled. Powerpc also needs these bits. Hence lets define the VM_PKEY_BITx bits for any architecture that enables CONFIG_ARCH_HAS_PKEYS. Signed-off-by: Ram Pai --- fs/proc/task_mmu.c |4 ++--

[PATCH v10 01/27] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS is enabled. Powerpc also needs these bits. Hence lets define the VM_PKEY_BITx bits for any architecture that enables CONFIG_ARCH_HAS_PKEYS. Signed-off-by: Ram Pai --- fs/proc/task_mmu.c |4 ++-- include/linux/mm.h |

[PATCH v10 14/27] powerpc: map vma key-protection bits to pte key bits.

Map the key protection bits of the vma to the pkey bits in the PTE. The PTE bits used for pkey are 3,4,5,6 and 57. The first four bits are the same four bits that were freed up initially in this patch series. remember? :-) Without those four bits this patch wouldn't be possible. BUT,

[PATCH v10 15/27] powerpc: Program HPTE key protection bits

Map the PTE protection key bits to the HPTE key protection bits, while creating HPTE entries. Acked-by: Balbir Singh Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/mmu-hash.h |5 + arch/powerpc/include/asm/mmu_context.h

[PATCH v10 14/27] powerpc: map vma key-protection bits to pte key bits.

Map the key protection bits of the vma to the pkey bits in the PTE. The PTE bits used for pkey are 3,4,5,6 and 57. The first four bits are the same four bits that were freed up initially in this patch series. remember? :-) Without those four bits this patch wouldn't be possible. BUT,

[PATCH v10 15/27] powerpc: Program HPTE key protection bits

Map the PTE protection key bits to the HPTE key protection bits, while creating HPTE entries. Acked-by: Balbir Singh Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/mmu-hash.h |5 + arch/powerpc/include/asm/mmu_context.h|6 ++

[PATCH v10 16/27] powerpc: helper to validate key-access permissions of a pte

helper function that checks if the read/write/execute is allowed on the pte. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/pgtable.h |4 +++ arch/powerpc/include/asm/pkeys.h |9 arch/powerpc/mm/pkeys.c | 28

[PATCH v10 16/27] powerpc: helper to validate key-access permissions of a pte

helper function that checks if the read/write/execute is allowed on the pte. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/pgtable.h |4 +++ arch/powerpc/include/asm/pkeys.h |9 arch/powerpc/mm/pkeys.c | 28

[PATCH v10 21/27] powerpc: Deliver SEGV signal on pkey violation

The value of the pkey, whose protection got violated, is made available in si_pkey field of the siginfo structure. Signed-off-by: Ram Pai Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/include/asm/bug.h |1 +

[PATCH v10 21/27] powerpc: Deliver SEGV signal on pkey violation

The value of the pkey, whose protection got violated, is made available in si_pkey field of the siginfo structure. Signed-off-by: Ram Pai Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/include/asm/bug.h |1 + arch/powerpc/kernel/traps.c| 12 +++-

[PATCH v10 23/27] powerpc: Enable pkey subsystem

PAPR defines 'ibm,processor-storage-keys' property. It exports two values. The first value holds the number of data-access keys and the second holds the number of instruction-access keys. Due to a bug in the firmware, instruction-access keys is always reported as zero. However any key can be

[PATCH v10 23/27] powerpc: Enable pkey subsystem

PAPR defines 'ibm,processor-storage-keys' property. It exports two values. The first value holds the number of data-access keys and the second holds the number of instruction-access keys. Due to a bug in the firmware, instruction-access keys is always reported as zero. However any key can be

[PATCH v10 22/27] powerpc/ptrace: Add memory protection key regset

From: Thiago Jung Bauermann The AMR/IAMR/UAMOR are part of the program context. Allow it to be accessed via ptrace and through core files. Signed-off-by: Ram Pai Signed-off-by: Thiago Jung Bauermann ---

[PATCH v10 17/27] powerpc: check key protection for user page access

Make sure that the kernel does not access user pages without checking their key-protection. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/pgtable.h | 19 +++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git

[PATCH v10 17/27] powerpc: check key protection for user page access

Make sure that the kernel does not access user pages without checking their key-protection. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/pgtable.h | 19 +++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git

[PATCH v10 22/27] powerpc/ptrace: Add memory protection key regset

From: Thiago Jung Bauermann The AMR/IAMR/UAMOR are part of the program context. Allow it to be accessed via ptrace and through core files. Signed-off-by: Ram Pai Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/include/asm/pkeys.h|5 +++ arch/powerpc/include/uapi/asm/elf.h |

[PATCH v10 26/27] mm, x86 : introduce arch_pkeys_enabled()

Arch neutral code needs to know if the architecture supports protection keys to display protection key in smaps. Hence introducing arch_pkeys_enabled(). This patch also provides x86 implementation for arch_pkeys_enabled(). Signed-off-by: Ram Pai ---

[PATCH v10 26/27] mm, x86 : introduce arch_pkeys_enabled()

Arch neutral code needs to know if the architecture supports protection keys to display protection key in smaps. Hence introducing arch_pkeys_enabled(). This patch also provides x86 implementation for arch_pkeys_enabled(). Signed-off-by: Ram Pai --- arch/x86/include/asm/pkeys.h |1 +

[PATCH v10 25/27] powerpc: sys_pkey_mprotect() system call

Patch provides the ability for a process to associate a pkey with a address range. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/systbl.h |1 + arch/powerpc/include/asm/unistd.h |4 +--- arch/powerpc/include/uapi/asm/unistd.h |1 + 3 files

[PATCH v10 25/27] powerpc: sys_pkey_mprotect() system call

Patch provides the ability for a process to associate a pkey with a address range. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/systbl.h |1 + arch/powerpc/include/asm/unistd.h |4 +--- arch/powerpc/include/uapi/asm/unistd.h |1 + 3 files changed, 3 insertions(+), 3

[PATCH v10 24/27] powerpc: sys_pkey_alloc() and sys_pkey_free() system calls

Finally this patch provides the ability for a process to allocate and free a protection key. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/systbl.h |2 ++ arch/powerpc/include/asm/unistd.h |4 +--- arch/powerpc/include/uapi/asm/unistd.h |2 ++ 3

[PATCH v10 24/27] powerpc: sys_pkey_alloc() and sys_pkey_free() system calls

Finally this patch provides the ability for a process to allocate and free a protection key. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/systbl.h |2 ++ arch/powerpc/include/asm/unistd.h |4 +--- arch/powerpc/include/uapi/asm/unistd.h |2 ++ 3 files changed, 5

[PATCH v10 27/27] mm: display pkey in smaps if arch_pkeys_enabled() is true

Currently the architecture specific code is expected to display the protection keys in smap for a given vma. This can lead to redundant code and possibly to divergent formats in which the key gets displayed. This patch changes the implementation. It displays the pkey only if the

[PATCH v10 27/27] mm: display pkey in smaps if arch_pkeys_enabled() is true

Currently the architecture specific code is expected to display the protection keys in smap for a given vma. This can lead to redundant code and possibly to divergent formats in which the key gets displayed. This patch changes the implementation. It displays the pkey only if the

[PATCH v10 06/27] powerpc: helper functions to initialize AMR, IAMR and UAMOR registers

Introduce helper functions that can initialize the bits in the AMR, IAMR and UAMOR register; the bits that correspond to the given pkey. Reviewed-by: Thiago Jung Bauermann Signed-off-by: Ram Pai --- arch/powerpc/mm/pkeys.c | 47

[PATCH v10 19/27] powerpc: Handle exceptions caused by pkey violation

Handle Data and Instruction exceptions caused by memory protection-key. The CPU will detect the key fault if the HPTE is already programmed with the key. However if the HPTE is not hashed, a key fault will not be detected by the hardware. The software will detect pkey violation in such a case.

[PATCH v10 20/27] powerpc: introduce get_mm_addr_key() helper

get_mm_addr_key() helper returns the pkey associated with an address corresponding to a given mm_struct. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu.h |9 + arch/powerpc/mm/hash_utils_64.c | 24 2 files changed, 33

[PATCH v10 06/27] powerpc: helper functions to initialize AMR, IAMR and UAMOR registers

Introduce helper functions that can initialize the bits in the AMR, IAMR and UAMOR register; the bits that correspond to the given pkey. Reviewed-by: Thiago Jung Bauermann Signed-off-by: Ram Pai --- arch/powerpc/mm/pkeys.c | 47 +++ 1 files

[PATCH v10 19/27] powerpc: Handle exceptions caused by pkey violation

Handle Data and Instruction exceptions caused by memory protection-key. The CPU will detect the key fault if the HPTE is already programmed with the key. However if the HPTE is not hashed, a key fault will not be detected by the hardware. The software will detect pkey violation in such a case.

[PATCH v10 20/27] powerpc: introduce get_mm_addr_key() helper

get_mm_addr_key() helper returns the pkey associated with an address corresponding to a given mm_struct. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu.h |9 + arch/powerpc/mm/hash_utils_64.c | 24 2 files changed, 33 insertions(+), 0

[PATCH v10 09/27] powerpc: ability to create execute-disabled pkeys

powerpc has hardware support to disable execute on a pkey. This patch enables the ability to create execute-disabled keys. Signed-off-by: Ram Pai --- arch/powerpc/include/uapi/asm/mman.h |6 ++ arch/powerpc/mm/pkeys.c | 16 2 files

[PATCH v10 18/27] powerpc: implementation for arch_vma_access_permitted()

This patch provides the implementation for arch_vma_access_permitted(). Returns true if the requested access is allowed by pkey associated with the vma. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu_context.h |5 +++- arch/powerpc/mm/pkeys.c|

[PATCH v10 09/27] powerpc: ability to create execute-disabled pkeys

powerpc has hardware support to disable execute on a pkey. This patch enables the ability to create execute-disabled keys. Signed-off-by: Ram Pai --- arch/powerpc/include/uapi/asm/mman.h |6 ++ arch/powerpc/mm/pkeys.c | 16 2 files changed, 22

[PATCH v10 18/27] powerpc: implementation for arch_vma_access_permitted()

This patch provides the implementation for arch_vma_access_permitted(). Returns true if the requested access is allowed by pkey associated with the vma. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu_context.h |5 +++- arch/powerpc/mm/pkeys.c| 34

[PATCH v10 05/27] powerpc: helper function to read,write AMR,IAMR,UAMOR registers

Implements helper functions to read and write the key related registers; AMR, IAMR, UAMOR. AMR register tracks the read,write permission of a key IAMR register tracks the execute permission of a key UAMOR register enables and disables a key Acked-by: Balbir Singh

[PATCH v10 05/27] powerpc: helper function to read,write AMR,IAMR,UAMOR registers

Implements helper functions to read and write the key related registers; AMR, IAMR, UAMOR. AMR register tracks the read,write permission of a key IAMR register tracks the execute permission of a key UAMOR register enables and disables a key Acked-by: Balbir Singh Reviewed-by: Thiago Jung

[PATCH v10 08/27] powerpc: implementation for arch_set_user_pkey_access()

This patch provides the detailed implementation for a user to allocate a key and enable it in the hardware. It provides the plumbing, but it cannot be used till the system call is implemented. The next patch will do so. Reviewed-by: Thiago Jung Bauermann

[PATCH v10 08/27] powerpc: implementation for arch_set_user_pkey_access()

This patch provides the detailed implementation for a user to allocate a key and enable it in the hardware. It provides the plumbing, but it cannot be used till the system call is implemented. The next patch will do so. Reviewed-by: Thiago Jung Bauermann Signed-off-by: Ram Pai ---

[PATCH v10 07/27] powerpc: cleanup AMR, IAMR when a key is allocated or freed

Cleanup the bits corresponding to a key in the AMR, and IAMR register, when the key is newly allocated/activated or is freed. We dont want some residual bits cause the hardware enforce unintended behavior when the key is activated or freed. Reviewed-by: Thiago Jung Bauermann

[PATCH v10 03/27] powerpc: initial pkey plumbing

Basic plumbing to initialize the pkey system. Nothing is enabled yet. A later patch will enable it once all the infrastructure is in place. Signed-off-by: Ram Pai --- arch/powerpc/Kconfig | 15 + arch/powerpc/include/asm/mmu_context.h |

[PATCH v10 04/27] powerpc: track allocation status of all pkeys

Total 32 keys are available on power7 and above. However pkey 0,1 are reserved. So effectively we have 30 pkeys. On 4K kernels, we do not have 5 bits in the PTE to represent all the keys; we only have 3bits.Two of those keys are reserved; pkey 0 and pkey 1. So effectively we have 6

[PATCH v10 03/27] powerpc: initial pkey plumbing

Basic plumbing to initialize the pkey system. Nothing is enabled yet. A later patch will enable it once all the infrastructure is in place. Signed-off-by: Ram Pai --- arch/powerpc/Kconfig | 15 + arch/powerpc/include/asm/mmu_context.h |1 +

[PATCH v10 04/27] powerpc: track allocation status of all pkeys

Total 32 keys are available on power7 and above. However pkey 0,1 are reserved. So effectively we have 30 pkeys. On 4K kernels, we do not have 5 bits in the PTE to represent all the keys; we only have 3bits.Two of those keys are reserved; pkey 0 and pkey 1. So effectively we have 6

[PATCH v10 07/27] powerpc: cleanup AMR, IAMR when a key is allocated or freed

Cleanup the bits corresponding to a key in the AMR, and IAMR register, when the key is newly allocated/activated or is freed. We dont want some residual bits cause the hardware enforce unintended behavior when the key is activated or freed. Reviewed-by: Thiago Jung Bauermann Signed-off-by: Ram

[PATCH v10 00/27] powerpc, mm: Memory Protection Keys

Memory protection keys enable applications to protect its address space from inadvertent access from or corruption by itself. These patches along with the pte-bit freeing patch series enables the protection key feature on powerpc; 4k and 64k hashpage kernels. Will send the documentation and

[PATCH v10 00/27] powerpc, mm: Memory Protection Keys

Memory protection keys enable applications to protect its address space from inadvertent access from or corruption by itself. These patches along with the pte-bit freeing patch series enables the protection key feature on powerpc; 4k and 64k hashpage kernels. Will send the documentation and

[PATCH v10 02/27] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

Currently only 4bits are allocated in the vma flags to hold 16 keys. This is sufficient for x86. PowerPC supports 32 keys, which needs 5bits. This patch allocates an additional bit. Acked-by: Balbir Singh Signed-off-by: Ram Pai ---

[PATCH v10 02/27] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

Currently only 4bits are allocated in the vma flags to hold 16 keys. This is sufficient for x86. PowerPC supports 32 keys, which needs 5bits. This patch allocates an additional bit. Acked-by: Balbir Singh Signed-off-by: Ram Pai --- fs/proc/task_mmu.c |1 + include/linux/mm.h |3 ++-

linux-next: build warning after merge of the crypto tree

Hi Herbert, After merging the crypto tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/crypto/chelsio/chcr_algo.c: In function 'create_authenc_wr': drivers/crypto/chelsio/chcr_algo.c:2113:2: warning: this 'if' clause does not guard... [-Wmisleading-indentation]

linux-next: build warning after merge of the crypto tree

Hi Herbert, After merging the crypto tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/crypto/chelsio/chcr_algo.c: In function 'create_authenc_wr': drivers/crypto/chelsio/chcr_algo.c:2113:2: warning: this 'if' clause does not guard... [-Wmisleading-indentation]

Re: what trees/branches to test on syzbot

Hi Dmitry, On Tue, Jan 16, 2018 at 10:58:51AM +0100, Dmitry Vyukov wrote: On Tue, Jan 16, 2018 at 10:45 AM, Guenter Roeck wrote: On Mon, Jan 15, 2018 at 11:51 PM, Dmitry Vyukov wrote: Hello, Several people proposed that linux-next should not be tested

Re: what trees/branches to test on syzbot

Hi Dmitry, On Tue, Jan 16, 2018 at 10:58:51AM +0100, Dmitry Vyukov wrote: On Tue, Jan 16, 2018 at 10:45 AM, Guenter Roeck wrote: On Mon, Jan 15, 2018 at 11:51 PM, Dmitry Vyukov wrote: Hello, Several people proposed that linux-next should not be tested on syzbot. While some people suggested

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

Hello, On Thu, Jan 18, 2018 at 03:25:25PM -0800, Andy Lutomirski wrote: > I read the whitepaper that documented the new MSRs a couple days ago > and I'm now completely unable to find it. If anyone could send the > link, that would be great. I see Andrew posted a link. > From memory, however,

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

Hello, On Thu, Jan 18, 2018 at 03:25:25PM -0800, Andy Lutomirski wrote: > I read the whitepaper that documented the new MSRs a couple days ago > and I'm now completely unable to find it. If anyone could send the > link, that would be great. I see Andrew posted a link. > From memory, however,

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

On Thu, Jan 18, 2018 at 11:35:59AM -0500, Sinan Kaya wrote: > On 1/18/2018 12:32 AM, p...@codeaurora.org wrote: > > On 2018-01-18 08:26, Keith Busch wrote: > >> On Wed, Jan 17, 2018 at 08:27:39AM -0800, Sinan Kaya wrote: > >>> On 1/17/2018 5:37 AM, Oza Pawandeep wrote: > >>> > +static bool

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

On Thu, Jan 18, 2018 at 11:35:59AM -0500, Sinan Kaya wrote: > On 1/18/2018 12:32 AM, p...@codeaurora.org wrote: > > On 2018-01-18 08:26, Keith Busch wrote: > >> On Wed, Jan 17, 2018 at 08:27:39AM -0800, Sinan Kaya wrote: > >>> On 1/17/2018 5:37 AM, Oza Pawandeep wrote: > >>> > +static bool

Re: net: r8169: a question of memory barrier in the r8169 driver

On 2018/1/19 9:11, Francois Romieu wrote: Jia-Ju Bai : [...] The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) { netif_err(tp, drv, dev, "BUG! Tx Ring full when

Re: net: r8169: a question of memory barrier in the r8169 driver

On 2018/1/19 9:11, Francois Romieu wrote: Jia-Ju Bai : [...] The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) { netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n");

Re: [PATCH] rcu: refine structure rcu_node field for rcu boost

Hi Paul, This patch is optional. 1. It's true that the added #ifdef in rcu_read_unlock_special is a bad breaker. The patch follows the current code e.g. CONFIG_PROVE_RCU 2. Haven't evaluated the performance in system. Studying RCU and found that boost

Re: [PATCH] rcu: refine structure rcu_node field for rcu boost

Hi Paul, This patch is optional. 1. It's true that the added #ifdef in rcu_read_unlock_special is a bad breaker. The patch follows the current code e.g. CONFIG_PROVE_RCU 2. Haven't evaluated the performance in system. Studying RCU and found that boost

Re: net: r8169: a question of memory barrier in the r8169 driver

Jia-Ju Bai : [...] > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: > if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) { > netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n"); > goto err_stop_0; >

Re: net: r8169: a question of memory barrier in the r8169 driver

Jia-Ju Bai : [...] > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: > if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) { > netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n"); > goto err_stop_0; > } > But there is no

Re: net: r8169: a question of memory barrier in the r8169 driver

Peter Zijlstra : [...] > There is only 1 variable afaict. Memory barriers need at least 2 in > order to be able to do _anything_. I don't get your point: why don't {cur_tx, dirty_tx} qualify as said two variables ? -- Ueimor

Re: net: r8169: a question of memory barrier in the r8169 driver

Peter Zijlstra : [...] > There is only 1 variable afaict. Memory barriers need at least 2 in > order to be able to do _anything_. I don't get your point: why don't {cur_tx, dirty_tx} qualify as said two variables ? -- Ueimor

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

Hi JC, Will, On 01/18/2018 06:28 PM, Jayachandran C wrote: > On Thu, Jan 18, 2018 at 01:27:15PM -0500, Jon Masters wrote: >> On 01/18/2018 12:56 PM, Jayachandran C wrote: >>> On Thu, Jan 18, 2018 at 01:53:55PM +, Will Deacon wrote: >>> I think in this case we have to choose between crashing

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

Hi JC, Will, On 01/18/2018 06:28 PM, Jayachandran C wrote: > On Thu, Jan 18, 2018 at 01:27:15PM -0500, Jon Masters wrote: >> On 01/18/2018 12:56 PM, Jayachandran C wrote: >>> On Thu, Jan 18, 2018 at 01:53:55PM +, Will Deacon wrote: >>> I think in this case we have to choose between crashing

Re: [PATCH] bridge: return boolean instead of integer in br_multicast_is_router

Quoting Stephen Hemminger : On Thu, 18 Jan 2018 17:37:45 -0600 "Gustavo A. R. Silva" wrote: Return statements in functions returning bool should use true/false instead of 1/0. This issue was detected with the help of Coccinelle.

Re: [PATCH] bridge: return boolean instead of integer in br_multicast_is_router

Quoting Stephen Hemminger : On Thu, 18 Jan 2018 17:37:45 -0600 "Gustavo A. R. Silva" wrote: Return statements in functions returning bool should use true/false instead of 1/0. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva LGTM Fixes:

Re: [PATCH] mm: numa: Do not trap faults on shared data section pages.

> On Jan 17, 2018, at 10:23 AM, Christopher Lameter wrote: > > On Tue, 16 Jan 2018, Mel Gorman wrote: > >> My main source of discomfort is the fact that this is permanent as two >> processes perfectly isolated but with a suitably shared COW mapping >> will never migrate the

Re: [PATCH] mm: numa: Do not trap faults on shared data section pages.

> On Jan 17, 2018, at 10:23 AM, Christopher Lameter wrote: > > On Tue, 16 Jan 2018, Mel Gorman wrote: > >> My main source of discomfort is the fact that this is permanent as two >> processes perfectly isolated but with a suitably shared COW mapping >> will never migrate the data. A potential

Re: [PATCH 1/3] Input: synaptics_rmi4 - do not delete interrupt memory too early

Reviewed-by: Lyude Paul (hope you don't mind that I'm using my gmail address for this ;) On Thu, 2018-01-18 at 16:49 -0800, Dmitry Torokhov wrote: > We want to free memory reserved for interrupt mask handling only after we > free functions, as function drivers might want to

Re: [PATCH 1/3] Input: synaptics_rmi4 - do not delete interrupt memory too early

Reviewed-by: Lyude Paul (hope you don't mind that I'm using my gmail address for this ;) On Thu, 2018-01-18 at 16:49 -0800, Dmitry Torokhov wrote: > We want to free memory reserved for interrupt mask handling only after we > free functions, as function drivers might want to mask interrupts. This

RE: [PATCH v3] x86/microcode/intel: Extend BDW late-loading with LLC size check

if (c->x86 == 6 && c->x86_model == INTEL_FAM6_BROADWELL_X && c->x86_mask == 0x01 && + llc_size_per_core > 2621440 && c->microcode < 0x0b21) { pr_err_once("Erratum BDF90: late loading with revision < 0x0b21 (0x%x)

RE: [PATCH v3] x86/microcode/intel: Extend BDW late-loading with LLC size check

if (c->x86 == 6 && c->x86_model == INTEL_FAM6_BROADWELL_X && c->x86_mask == 0x01 && + llc_size_per_core > 2621440 && c->microcode < 0x0b21) { pr_err_once("Erratum BDF90: late loading with revision < 0x0b21 (0x%x)

[PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3

On 01/09/2018 05:00 AM, Will Deacon wrote: > On Mon, Jan 08, 2018 at 08:06:27PM -0800, Jayachandran C wrote: >> On Mon, Jan 08, 2018 at 05:51:00PM +, Will Deacon wrote: >>> On Mon, Jan 08, 2018 at 09:40:17AM -0800, Jayachandran C wrote: On Mon, Jan 08, 2018 at 09:20:09AM +, Marc

Re: [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3

On 01/09/2018 05:00 AM, Will Deacon wrote: > On Mon, Jan 08, 2018 at 08:06:27PM -0800, Jayachandran C wrote: >> On Mon, Jan 08, 2018 at 05:51:00PM +, Will Deacon wrote: >>> On Mon, Jan 08, 2018 at 09:40:17AM -0800, Jayachandran C wrote: On Mon, Jan 08, 2018 at 09:20:09AM +, Marc

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: kernel/bpf/verifier.c between commit: 6f16101e6a8b ("bpf: mark dst unknown on inconsistent {s, u}bounds adjustments") from the net tree and commit: f4d7e40a5b71 ("bpf: introduce function calls (verification)")

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: kernel/bpf/verifier.c between commit: 6f16101e6a8b ("bpf: mark dst unknown on inconsistent {s, u}bounds adjustments") from the net tree and commit: f4d7e40a5b71 ("bpf: introduce function calls (verification)")

Re: [PATCH 4.4 045/115] sched/deadline: Throttle a constrained deadline task activated after the deadline

On Mon, 2017-12-18 at 16:48 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me > know. > > -- > > From: Daniel Bristot de Oliveira > > > [ Upstream commit df8eac8cafce7d086be3bd5cf5a838fa37594dfb ] [...]

Re: [PATCH 4.4 045/115] sched/deadline: Throttle a constrained deadline task activated after the deadline

On Mon, 2017-12-18 at 16:48 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me > know. > > -- > > From: Daniel Bristot de Oliveira > > > [ Upstream commit df8eac8cafce7d086be3bd5cf5a838fa37594dfb ] [...] I think this needs

Re: KASAN: slab-out-of-bounds Read in __dev_queue_xmit

On Thu, 2018-01-18 at 15:58 -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on linux-next commit > 0e08c463db387a2adcb0243b15ab868a73f87807 > > So far this crash happened 6 times on linux-next, mmots, upstream. > C reproducer is attached. > syzkaller reproducer is attached. >

Re: KASAN: slab-out-of-bounds Read in __dev_queue_xmit

On Thu, 2018-01-18 at 15:58 -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on linux-next commit > 0e08c463db387a2adcb0243b15ab868a73f87807 > > So far this crash happened 6 times on linux-next, mmots, upstream. > C reproducer is attached. > syzkaller reproducer is attached. >

[PATCH 1/3] Input: synaptics_rmi4 - do not delete interrupt memory too early

We want to free memory reserved for interrupt mask handling only after we free functions, as function drivers might want to mask interrupts. This is needed for the followup patch to the F03 that would implement unmasking and masking interrupts from the serio pass-through port open() and close()

[PATCH 1/3] Input: synaptics_rmi4 - do not delete interrupt memory too early

We want to free memory reserved for interrupt mask handling only after we free functions, as function drivers might want to mask interrupts. This is needed for the followup patch to the F03 that would implement unmasking and masking interrupts from the serio pass-through port open() and close()

[PATCH 0/3] RMI4: improve trackpoint detection

Hi, The following patch series is hopefully improves trackpint detection on systems using RMI4 and PS/2 guest modules. The issue was that we were registering port too early, before RMI driver was ready to service interrupts properly, so psmouse would try to get ID from the device and RMI driver

[PATCH 0/3] RMI4: improve trackpoint detection

Hi, The following patch series is hopefully improves trackpint detection on systems using RMI4 and PS/2 guest modules. The issue was that we were registering port too early, before RMI driver was ready to service interrupts properly, so psmouse would try to get ID from the device and RMI driver

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