[RFC PATCH] security: Add a config option to disable security mitigations

-by: Pranith Kumar --- kernel/cpu.c | 2 +- security/Kconfig | 8 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/kernel/cpu.c b/kernel/cpu.c index 6ff2578ecf17..584eb39585d6 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -2542,7 +2542,7 @@ early_param("mitiga

Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee

Hi Paul, On Mon, Nov 14, 2016 at 11:47 AM, Paul E. McKenney wrote: > Recent memory-model work deduces the relationships of RCU read-side > critical sections and grace periods based on the relationships of > accesses within a critical section and accesses preceding and

Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee

Hi Paul, On Mon, Nov 14, 2016 at 11:47 AM, Paul E. McKenney wrote: > Recent memory-model work deduces the relationships of RCU read-side > critical sections and grace periods based on the relationships of > accesses within a critical section and accesses preceding and following > the grace

[PATCH] Documentation/RCU: Fix minor typo

deference should actually be dereference. Signed-off-by: Pranith Kumar <bobby.pr...@gmail.com> --- Documentation/RCU/whatisRCU.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 2044227..5cbd8b2

[PATCH] Documentation/RCU: Fix minor typo

deference should actually be dereference. Signed-off-by: Pranith Kumar --- Documentation/RCU/whatisRCU.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 2044227..5cbd8b2 100644 --- a/Documentation/RCU

[PATCH] scsi: Remove unnecessary comparison

val is an unsigned int which makes the comparison >=0 unnecessary. This patch removes it. Signed-off-by: Pranith Kumar <bobby.pr...@gmail.com> --- drivers/scsi/sd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index d3e852a

[PATCH] scsi: Remove unnecessary comparison

val is an unsigned int which makes the comparison >=0 unnecessary. This patch removes it. Signed-off-by: Pranith Kumar --- drivers/scsi/sd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index d3e852a..7a919b2 100644 --- a/drivers/s

Re: [PATCH tip/core/rcu 04/12] rcu: Move expedited code from tree.c to tree_exp.h

Hi Paul, On Wed, Jun 15, 2016 at 5:46 PM, Paul E. McKenney wrote: > People have been having some difficulty finding their way around the > RCU code. This commit therefore pulls some of the expedited grace-period > code from tree.c to a new tree_exp.h file. This

Re: [PATCH tip/core/rcu 04/12] rcu: Move expedited code from tree.c to tree_exp.h

Hi Paul, On Wed, Jun 15, 2016 at 5:46 PM, Paul E. McKenney wrote: > People have been having some difficulty finding their way around the > RCU code. This commit therefore pulls some of the expedited grace-period > code from tree.c to a new tree_exp.h file. This commit is strictly code >

Re: [PATCH] kvm: Fix build error caused by redefinition

Hi Paolo, Paolo Bonzini writes: > > Please test this instead: This patch works for me. Please feel free to add: Tested-by: Pranith Kumar <bobby.pr...@gmail.com> > > diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile > index 7f7b6d86ac73..eba0bea6e03

Re: [PATCH] kvm: Fix build error caused by redefinition

Hi Paolo, Paolo Bonzini writes: > > Please test this instead: This patch works for me. Please feel free to add: Tested-by: Pranith Kumar > > diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile > index 7f7b6d86ac73..eba0bea6e032 100644 > --- a/arch/powerpc/kv

[PATCH] kvm: Fix build error caused by redefinition

/Makefile.build:258: recipe for target 'arch/powerpc/kvm/../../../virt/kvm/vfio.o' failed make[3]: *** [arch/powerpc/kvm/../../../virt/kvm/vfio.o] Error 1 Fix it by enclosing the definitions within CONFIG_KVM_VFIO Signed-off-by: Pranith Kumar <bobby.pr...@gmail.com> --- virt/kvm/vfio.c | 2

[PATCH] kvm: Fix build error caused by redefinition

/Makefile.build:258: recipe for target 'arch/powerpc/kvm/../../../virt/kvm/vfio.o' failed make[3]: *** [arch/powerpc/kvm/../../../virt/kvm/vfio.o] Error 1 Fix it by enclosing the definitions within CONFIG_KVM_VFIO Signed-off-by: Pranith Kumar --- virt/kvm/vfio.c | 2 ++ 1 file changed, 2

Re: [PATCH] init: print warning message if /dev/console failed to open

Hello Alexander, On Wed, Feb 3, 2016 at 1:58 PM, Alexander Kuleshov wrote: > Signed-off-by: Alexander Kuleshov Please describe the changes in each patch. Why do you need this warning? If you haven't read it yet, please read (esp. Section 2):

Re: [PATCH] init: print warning message if /dev/console failed to open

Hello Alexander, On Wed, Feb 3, 2016 at 1:58 PM, Alexander Kuleshov wrote: > Signed-off-by: Alexander Kuleshov Please describe the changes in each patch. Why do you need this warning? If you haven't read it yet, please read (esp. Section 2):

Re: [RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

On Tue, Jan 26, 2016 at 12:45 AM, Pranith Kumar wrote: > On Mon, Jan 25, 2016 at 10:13 PM, Michael Ellerman > wrote: >> On Mon, 2016-01-25 at 09:22 -0500, Pranith Kumar wrote: >> >>> In 4.5-rc1, I am getting a build failure as follows: >>> >>> mm

Re: [RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

On Tue, Jan 26, 2016 at 12:45 AM, Pranith Kumar <bobby.pr...@gmail.com> wrote: > On Mon, Jan 25, 2016 at 10:13 PM, Michael Ellerman <m...@ellerman.id.au> > wrote: >> On Mon, 2016-01-25 at 09:22 -0500, Pranith Kumar wrote: >> >>> In 4.5-rc1, I am getting

qemu fails to build on 4.5-rc1

Hi Dave, Commit 334e580a6f97 ("fs: XFS_IOC_FS[SG]SETXATTR to FS_IOC_FS[SG]ETXATTR promotion") breaks building latest qemu as follows: In file included from /usr/include/xfs/xfs.h:58:0, from /home/pranith/qemu/block/raw-posix.c:96: /usr/include/xfs/xfs_fs.h:42:8: error:

qemu fails to build on 4.5-rc1

Hi Dave, Commit 334e580a6f97 ("fs: XFS_IOC_FS[SG]SETXATTR to FS_IOC_FS[SG]ETXATTR promotion") breaks building latest qemu as follows: In file included from /usr/include/xfs/xfs.h:58:0, from /home/pranith/qemu/block/raw-posix.c:96: /usr/include/xfs/xfs_fs.h:42:8: error:

Re: [RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

On Mon, Jan 25, 2016 at 10:13 PM, Michael Ellerman wrote: > On Mon, 2016-01-25 at 09:22 -0500, Pranith Kumar wrote: > >> In 4.5-rc1, I am getting a build failure as follows: >> >> mm/memory.c: In function ‘do_swap_page’: >> mm/memory.c:2573:9: error: im

[RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

for PPC64 on PPC_BOOK3S in arch/powerpc/include/asm/book3s/64/hash.h and missing in the 32-bit arch. Avoid this error by not setting HAVE_ARCH_SOFT_DIRTY for 32-bit system. Signed-off-by: Pranith Kumar --- arch/powerpc/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

On Mon, Jan 25, 2016 at 10:13 PM, Michael Ellerman <m...@ellerman.id.au> wrote: > On Mon, 2016-01-25 at 09:22 -0500, Pranith Kumar wrote: > >> In 4.5-rc1, I am getting a build failure as follows: >> >> mm/memory.c: In function ‘do_swap_page’: >> mm/memory.c

[RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

for PPC64 on PPC_BOOK3S in arch/powerpc/include/asm/book3s/64/hash.h and missing in the 32-bit arch. Avoid this error by not setting HAVE_ARCH_SOFT_DIRTY for 32-bit system. Signed-off-by: Pranith Kumar <bobby.pr...@gmail.com> --- arch/powerpc/Kconfig | 4 ++-- 1 file changed, 2 insertions

[PATCH] llist: Use for() initializer and conditional

Simplify the code a bit by using the initializer and conditional check in for() instead of a separate if() statement in the loop. Signed-off-by: Pranith Kumar --- lib/llist.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/lib/llist.c b/lib/llist.c index ae5872b..ddbeebb

[PATCH] llist: Use for() initializer and conditional

Simplify the code a bit by using the initializer and conditional check in for() instead of a separate if() statement in the loop. Signed-off-by: Pranith Kumar <bobby.pr...@gmail.com> --- lib/llist.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/lib/llist.c b/lib/l

[PATCH] llist: Use for conditional in llist_del_first()

Simplify the code a bit by using the initializer and conditional check in for() instead of a separate if() statement in the loop. Signed-off-by: Pranith Kumar --- lib/llist.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/lib/llist.c b/lib/llist.c index 0b0e977..03d7aad

[PATCH] llist: Use for conditional in llist_del_first()

Simplify the code a bit by using the initializer and conditional check in for() instead of a separate if() statement in the loop. Signed-off-by: Pranith Kumar <bobby.pr...@gmail.com> --- lib/llist.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/lib/llist.c b/lib/l

Re: bindeb-pkg error (was Re: kbuild misc changes for v4.3-rc1 )

On Mon, Oct 12, 2015 at 1:04 AM, Jim Davis wrote: > On Sun, Oct 11, 2015 at 7:58 PM, Pranith Kumar > wrote: >> >> >> ../linux-firmware-image-4.3.0-rc4_4.3.0-rc4-7_powerpc.deb: No such >> file or directory >> scripts/package/Makefile:97: recipe for

Re: bindeb-pkg error (was Re: kbuild misc changes for v4.3-rc1 )

On Mon, Oct 12, 2015 at 1:04 AM, Jim Davis <jim.ep...@gmail.com> wrote: > On Sun, Oct 11, 2015 at 7:58 PM, Pranith Kumar > <bobby.prani+l...@gmail.com> wrote: >> >> >> ../linux-firmware-image-4.3.0-rc4_4.3.0-rc4-7_powerpc.deb: No such >> file or direct

bindeb-pkg error (was Re: kbuild misc changes for v4.3-rc1 )

Hi Michal, On Tue, Sep 8, 2015 at 11:38 AM, Michal Marek wrote: > Hi Linus, > > these are the non-core kbuild changes for 4.3-rc1: > - deb-pkg: > + module signing fix > + dtb files are added to the package > + do not require `hostname -f` to work during build > + make deb-pkg generates a

bindeb-pkg error (was Re: kbuild misc changes for v4.3-rc1 )

Hi Michal, On Tue, Sep 8, 2015 at 11:38 AM, Michal Marek wrote: > Hi Linus, > > these are the non-core kbuild changes for 4.3-rc1: > - deb-pkg: > + module signing fix > + dtb files are added to the package > + do not require `hostname -f` to work during build > + make

[PATCH] doc: Clarify that nmi_watchdog param is for hardlockups

The kernel NMI watchdog acts as both a hardlockup and softlockup detector. However, the kernel parameter nmi_watchdog can only enable or disable the hardlockup detector. Clarify that in the documentation. Signed-off-by: Pranith Kumar --- Documentation/kernel-parameters.txt | 7 --- 1 file

[PATCH] doc: Clarify that nmi_watchdog param is for hardlockups

The kernel NMI watchdog acts as both a hardlockup and softlockup detector. However, the kernel parameter nmi_watchdog can only enable or disable the hardlockup detector. Clarify that in the documentation. Signed-off-by: Pranith Kumar <bobby.pr...@gmail.com> --- Documentation/

Re: [PATCH] x86: cmpxchg_double: Add missing memory clobber

On Tue, Oct 6, 2015 at 4:16 PM, H. Peter Anvin wrote: > > NAK. We already have the "+m" for exactly this reason; adding an > explicit memory clobber should only be used to prevent movement of > *other* memory operations around this one (i.e. a barrier). > OK. If that is so, can you please

[PATCH] x86: cmpxchg_double: Add missing memory clobber

We are reading from memory locations pointed to by p1 and p2 in the asm block. Add a memory clobber flag to make gcc aware of this. Signed-off-by: Pranith Kumar --- arch/x86/include/asm/cmpxchg.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm

[PATCH] x86: cmpxchg_double: Add missing memory clobber

We are reading from memory locations pointed to by p1 and p2 in the asm block. Add a memory clobber flag to make gcc aware of this. Signed-off-by: Pranith Kumar <bobby.pr...@gmail.com> --- arch/x86/include/asm/cmpxchg.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH] x86: cmpxchg_double: Add missing memory clobber

On Tue, Oct 6, 2015 at 4:16 PM, H. Peter Anvin wrote: > > NAK. We already have the "+m" for exactly this reason; adding an > explicit memory clobber should only be used to prevent movement of > *other* memory operations around this one (i.e. a barrier). > OK. If that is so, can

Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants

On Wed, Sep 2, 2015 at 11:23 AM, Pranith Kumar wrote: > Hi Will, > > On 09/02/2015 05:59 AM, Will Deacon wrote: >> I just thought it was worth making this point, because it is prohibited >> in SC and I don't want people to think that our RELEASE/ACQUIRE operations &

Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants

Hi Will, On 09/02/2015 05:59 AM, Will Deacon wrote: > I just thought it was worth making this point, because it is prohibited > in SC and I don't want people to think that our RELEASE/ACQUIRE operations > are SC (even though they happen to be on arm64). This is interesting information. Does that

Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants

Hi Will, On 09/02/2015 05:59 AM, Will Deacon wrote: > I just thought it was worth making this point, because it is prohibited > in SC and I don't want people to think that our RELEASE/ACQUIRE operations > are SC (even though they happen to be on arm64). This is interesting information. Does that

Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants

On Wed, Sep 2, 2015 at 11:23 AM, Pranith Kumar <bobby.pr...@gmail.com> wrote: > Hi Will, > > On 09/02/2015 05:59 AM, Will Deacon wrote: >> I just thought it was worth making this point, because it is prohibited >> in SC and I don't want people to think that our RELEASE/A

Re: membarrier selftest issue

Hi Mathieu, On Mon, Jun 15, 2015 at 11:31 AM, Mathieu Desnoyers wrote: > Hi, > > The updated membarrier tree: > https://github.com/compudj/linux-dev > branch: sys-membarrier-volatile > > has an issue building selftests (make -C tools/testing/selftests) > > It appears that including

Re: membarrier selftest issue

Hi Mathieu, On Mon, Jun 15, 2015 at 11:31 AM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: Hi, The updated membarrier tree: https://github.com/compudj/linux-dev branch: sys-membarrier-volatile has an issue building selftests (make -C tools/testing/selftests) It appears that

Re: [PATCH] kernel:signal - Fix for typos in comments.

On Sat, May 23, 2015 at 1:09 AM, Shailendra Verma wrote: Please include a changelog for every patch you submit exolaining why you think the change makes sense. > > Signed-off-by: Shailendra Verma > --- > kernel/signal.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff

Re: [PATCH] kernel:signal - Fix for typos in comments.

On Sat, May 23, 2015 at 1:09 AM, Shailendra Verma wrote: Please include a changelog for every patch you submit exolaining why you think the change makes sense. Signed-off-by: Shailendra Verma shailendra.capric...@gmail.com --- kernel/signal.c |4 ++-- 1 file changed, 2 insertions(+), 2

Re: [PATCH] compiler-intel: fix wrong compiler barrier() macro

On Wed, Apr 29, 2015 at 12:59 PM, Daniel Borkmann wrote: > On 04/29/2015 06:40 PM, Pranith Kumar wrote: >> >> On Wed, Apr 29, 2015 at 10:59 AM, mancha security >> wrote: >>> >>> >>> The problem is that ICC defines __GNUC__ so barrier() gets de

Re: [PATCH] compiler-intel: fix wrong compiler barrier() macro

On Wed, Apr 29, 2015 at 10:59 AM, mancha security wrote: > > The problem is that ICC defines __GNUC__ so barrier() gets defined > in compiler-gcc.h. Your commit removed an #undef from compiler-intel.h > so compiler.h will never define barrier to __memory_barrier(). > OK, I see your point. But,

Re: [PATCH] compiler-intel: fix wrong compiler barrier() macro

Hi Daniel, On Wed, Apr 29, 2015 at 10:42 AM, Daniel Borkmann wrote: > Cleanup commit 23ebdedc67e ("compiler-intel.h: Remove duplicate > definition") removed the double definition of __memory_barrier() > intrinsics. > > However, in doing so, it also removed the preceding #undef barrier, >

Re: [PATCH] compiler-intel: fix wrong compiler barrier() macro

On Wed, Apr 29, 2015 at 10:59 AM, mancha security manc...@zoho.com wrote: The problem is that ICC defines __GNUC__ so barrier() gets defined in compiler-gcc.h. Your commit removed an #undef from compiler-intel.h so compiler.h will never define barrier to __memory_barrier(). OK, I see your

Re: [PATCH] compiler-intel: fix wrong compiler barrier() macro

On Wed, Apr 29, 2015 at 12:59 PM, Daniel Borkmann dan...@iogearbox.net wrote: On 04/29/2015 06:40 PM, Pranith Kumar wrote: On Wed, Apr 29, 2015 at 10:59 AM, mancha security manc...@zoho.com wrote: The problem is that ICC defines __GNUC__ so barrier() gets defined in compiler-gcc.h. Your

Re: [PATCH] compiler-intel: fix wrong compiler barrier() macro

Hi Daniel, On Wed, Apr 29, 2015 at 10:42 AM, Daniel Borkmann dan...@iogearbox.net wrote: Cleanup commit 23ebdedc67e (compiler-intel.h: Remove duplicate definition) removed the double definition of __memory_barrier() intrinsics. However, in doing so, it also removed the preceding #undef

Re: [PATCH v16] sys_membarrier(): system-wide memory barrier (generic, x86)

On Wed, Apr 22, 2015 at 4:40 PM, Mathieu Desnoyers wrote: > - Original Message - >> On Fri, Apr 17, 2015 at 11:06 AM, Mathieu Desnoyers >> wrote: >> > diff --git a/init/Kconfig b/init/Kconfig >> > index f5dbc6d..89bad6a 100644 >> > --- a/init/Kconfig >> > +++ b/init/Kconfig >> > @@

Re: [PATCH v16] sys_membarrier(): system-wide memory barrier (generic, x86)

On Fri, Apr 17, 2015 at 11:06 AM, Mathieu Desnoyers wrote: > diff --git a/init/Kconfig b/init/Kconfig > index f5dbc6d..89bad6a 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1559,6 +1559,19 @@ config PCI_QUIRKS > bugs/quirks. Disable this only if your target machine is >

Re: [PATCH v16] sys_membarrier(): system-wide memory barrier (generic, x86)

On Wed, Apr 22, 2015 at 4:40 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: - Original Message - On Fri, Apr 17, 2015 at 11:06 AM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: diff --git a/init/Kconfig b/init/Kconfig index f5dbc6d..89bad6a 100644 ---

Re: [PATCH v16] sys_membarrier(): system-wide memory barrier (generic, x86)

On Fri, Apr 17, 2015 at 11:06 AM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: diff --git a/init/Kconfig b/init/Kconfig index f5dbc6d..89bad6a 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1559,6 +1559,19 @@ config PCI_QUIRKS bugs/quirks. Disable this only if your

Re: [PATCH tip/core/rcu 0/12] RCU Kconfig fixes for v4.2

RCU_FANOUT behind RCU_EXPERT. > > 11. Change RCU to allow it to tolerate an undefined RCU_FANOUT_LEAF, > and then hide RCU_FANOUT_LEAF behind RCU_EXPERT. > > 12. Change RCU to allow it to tolerate an undefined RCU_KTHREAD_PRIO, > and then hide RCU_KTHREAD_PRI

Re: [PATCH tip/core/rcu 11/12] rcu: Make RCU able to tolerate undefined CONFIG_RCU_FANOUT_LEAF

On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney wrote: > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > index 2e52502bfc95..a2f64e4fdb57 100644 > --- a/kernel/rcu/tree_plugin.h > +++ b/kernel/rcu/tree_plugin.h > @@ -86,10 +86,10 @@ static void __init

Re: [PATCH tip/core/rcu 09/12] rcu: Break dependency of RCU_FANOUT_LEAF on RCU_FANOUT

On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > RCU_FANOUT_LEAF's range and default values depend on the value of > RCU_FANOUT, which at the time seemed like a cute way to save two lines > of Kconfig code. However, adding a dependency from both of these >

Re: [PATCH tip/core/rcu 05/12] rcutorture: Update configuration fragments for rcutree.rcu_fanout_exact

On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > This commit updates rcutortures configuration-fragment files to account > for the move from the CONFIG_RCU_FANOUT_EXACT Kconfig parameter to the > new rcutree.rcu_fanout_exact= boot parameter. > >

[RFC PATCH] rcu: config: Remove prompt for RCU implementation

The RCU implementation which is chosen is dependent on PREEMPT and SMP config options and is not really a user-selectable choice. The following change will remove the menu entry and will be derived from the above two options. Signed-off-by: Pranith Kumar --- init/Kconfig | 18

Re: [PATCH tip/core/rcu 05/12] rcutorture: Update configuration fragments for rcutree.rcu_fanout_exact

On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: From: Paul E. McKenney paul...@linux.vnet.ibm.com This commit updates rcutortures configuration-fragment files to account for the move from the CONFIG_RCU_FANOUT_EXACT Kconfig parameter to the new

Re: [PATCH tip/core/rcu 09/12] rcu: Break dependency of RCU_FANOUT_LEAF on RCU_FANOUT

On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: From: Paul E. McKenney paul...@linux.vnet.ibm.com RCU_FANOUT_LEAF's range and default values depend on the value of RCU_FANOUT, which at the time seemed like a cute way to save two lines of Kconfig code.

Re: [PATCH tip/core/rcu 11/12] rcu: Make RCU able to tolerate undefined CONFIG_RCU_FANOUT_LEAF

On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 2e52502bfc95..a2f64e4fdb57 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -86,10 +86,10 @@ static void __init

Re: [PATCH tip/core/rcu 0/12] RCU Kconfig fixes for v4.2

to allow it to tolerate an undefined RCU_KTHREAD_PRIO, and then hide RCU_KTHREAD_PRIO behind RCU_EXPERT. Thanx, Paul With or without the minor changes: Reviewed-by: Pranith Kumar bobby.pr...@gmail.com -- Pranith -- To unsubscribe

[RFC PATCH] rcu: config: Remove prompt for RCU implementation

The RCU implementation which is chosen is dependent on PREEMPT and SMP config options and is not really a user-selectable choice. The following change will remove the menu entry and will be derived from the above two options. Signed-off-by: Pranith Kumar bobby.pr...@gmail.com --- init/Kconfig

Re: [PATCH] rcu: small rcu_dereference doc update

On Fri, Apr 17, 2015 at 12:15 PM, Paul E. McKenney wrote: > Sounds like a good thought for a separate patch. Please take a look > through the rest of the documentation -- this might well be the right > place for such an example, but there might well be a better place. > Is this issue mentioned

Re: [PATCH] rcu: small rcu_dereference doc update

On Fri, Apr 17, 2015 at 6:33 AM, Milos Vyletel wrote: > Make a note stating that repeated calls of rcu_dereference() may not > return the same pointer if update happens while in critical section. Might as well make it more explicit with an example then. See below: > > Reported-by: Jeff Haran >

Re: [PATCH] rcu: small rcu_dereference doc update

On Fri, Apr 17, 2015 at 12:15 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Sounds like a good thought for a separate patch. Please take a look through the rest of the documentation -- this might well be the right place for such an example, but there might well be a better place. Is

Re: [PATCH] rcu: small rcu_dereference doc update

On Fri, Apr 17, 2015 at 6:33 AM, Milos Vyletel mi...@redhat.com wrote: Make a note stating that repeated calls of rcu_dereference() may not return the same pointer if update happens while in critical section. Might as well make it more explicit with an example then. See below: Reported-by:

[PATCH] README: Update references to version 4

Since we bumped the version to 4.0, let us update the references to match that in the README file. Signed-off-by: Pranith Kumar --- README | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/README b/README index a24ec89..dbe9c96 100644

[PATCH] README: Update references to version 4

Since we bumped the version to 4.0, let us update the references to match that in the README file. Signed-off-by: Pranith Kumar bobby.pr...@gmail.com --- README | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/README b/README index

[PATCH] nouveau: gt215: Fix clock freq. calculation

In commit 6a4a47cfd181 ("drm/nva3/clk: Set PLL refclk") diff was changed from int to u32 because of which a later branch which was testing if (diff < 0) became always false. Fix this by using int type for diff. Signed-off-by: Pranith Kumar CC: sta...@vger.kernel.org CC: Roy Sp

Re: linux panic on 4.0.0-rc4

On Tue, Mar 17, 2015 at 4:13 PM, Peter Hurley wrote: > On 03/17/2015 04:07 PM, Pranith Kumar wrote: >> On Tue, Mar 17, 2015 at 4:03 PM, Peter Hurley >> wrote: >>> >>> Can you send me a complete dmesg capture from a boot with >>> this commit reverted

Re: linux panic on 4.0.0-rc4

On Tue, Mar 17, 2015 at 4:03 PM, Peter Hurley wrote: > > Can you send me a complete dmesg capture from a boot with > this commit reverted? > Here it is. Let me know if you want any boot options enabled. I removed both debug and verbose boot options. [0.00] Using PowerMac machine

Re: linux panic on 4.0.0-rc4

On Mon, Mar 16, 2015 at 11:18 PM, Peter Hurley wrote: > On 03/16/2015 11:12 PM, Pranith Kumar wrote: >> On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley >> wrote: >>>>> What is your init? >>>> >>>> I am using systemd from debian unstable. >

Re: linux panic on 4.0.0-rc4

On Mon, Mar 16, 2015 at 11:18 PM, Peter Hurley pe...@hurleysoftware.com wrote: On 03/16/2015 11:12 PM, Pranith Kumar wrote: On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley pe...@hurleysoftware.com wrote: What is your init? I am using systemd from debian unstable. Do you have a stdout-path

[PATCH] nouveau: gt215: Fix clock freq. calculation

In commit 6a4a47cfd181 (drm/nva3/clk: Set PLL refclk) diff was changed from int to u32 because of which a later branch which was testing if (diff 0) became always false. Fix this by using int type for diff. Signed-off-by: Pranith Kumar bobby.pr...@gmail.com CC: sta...@vger.kernel.org CC: Roy

Re: linux panic on 4.0.0-rc4

On Tue, Mar 17, 2015 at 4:03 PM, Peter Hurley pe...@hurleysoftware.com wrote: Can you send me a complete dmesg capture from a boot with this commit reverted? Here it is. Let me know if you want any boot options enabled. I removed both debug and verbose boot options. [0.00] Using

Re: linux panic on 4.0.0-rc4

On Tue, Mar 17, 2015 at 4:13 PM, Peter Hurley pe...@hurleysoftware.com wrote: On 03/17/2015 04:07 PM, Pranith Kumar wrote: On Tue, Mar 17, 2015 at 4:03 PM, Peter Hurley pe...@hurleysoftware.com wrote: Can you send me a complete dmesg capture from a boot with this commit reverted? Here

Re: linux panic on 4.0.0-rc4

On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley wrote: >>> What is your init? >> >> I am using systemd from debian unstable. > > Do you have a stdout-path property defined in your dts to a serial > console you're not actually using? > I am using tty0 as my console. From the config which I posted,

Re: linux panic on 4.0.0-rc4

On Mon, Mar 16, 2015 at 7:22 PM, Michael Ellerman wrote: > > The log shows that init is being killed, that's what's causing the panic. > > The exitcode of init is 0x200, which due to the vagaries of UNIX is I think an > "exit status" of 2 in the common usage. > > But it suggests that your init is

Re: linux panic on 4.0.0-rc4

On Mon, Mar 16, 2015 at 4:16 AM, Michael Ellerman wrote: > On Mon, 2015-03-16 at 01:34 -0400, Pranith Kumar wrote: >> On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar wrote: >> > Hello, >> > >> > I have a power mac mini 32-bit system. >> > >>

Re: linux panic on 4.0.0-rc4

On Mon, Mar 16, 2015 at 7:22 PM, Michael Ellerman m...@ellerman.id.au wrote: The log shows that init is being killed, that's what's causing the panic. The exitcode of init is 0x200, which due to the vagaries of UNIX is I think an exit status of 2 in the common usage. But it suggests that

Re: linux panic on 4.0.0-rc4

On Mon, Mar 16, 2015 at 10:58 PM, Peter Hurley pe...@hurleysoftware.com wrote: What is your init? I am using systemd from debian unstable. Do you have a stdout-path property defined in your dts to a serial console you're not actually using? I am using tty0 as my console. From the config

Re: linux panic on 4.0.0-rc4

On Mon, Mar 16, 2015 at 4:16 AM, Michael Ellerman m...@ellerman.id.au wrote: On Mon, 2015-03-16 at 01:34 -0400, Pranith Kumar wrote: On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar bobby.pr...@gmail.com wrote: Hello, I have a power mac mini 32-bit system. ... You can see the panic

Re: linux panic on 4.0.0-rc4

On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar wrote: > Hello, > > I have a power mac mini 32-bit system. > ... > You can see the panic message here: http://imgur.com/s1lH15g. (there > is no log and I have no serial console). There was some debug code in there when it hit. The

linux panic on 4.0.0-rc4

Hello, I have a power mac mini 32-bit system. I am getting a kernel panic with the latest rc kernel. The last kernel which worked on this which I remember booting was 3.19-rc5. You can see the panic message here: http://imgur.com/s1lH15g. (there is no log and I have no serial console). Let me

linux panic on 4.0.0-rc4

Hello, I have a power mac mini 32-bit system. I am getting a kernel panic with the latest rc kernel. The last kernel which worked on this which I remember booting was 3.19-rc5. You can see the panic message here: http://imgur.com/s1lH15g. (there is no log and I have no serial console). Let me

Re: linux panic on 4.0.0-rc4

On Mon, Mar 16, 2015 at 1:11 AM, Pranith Kumar bobby.pr...@gmail.com wrote: Hello, I have a power mac mini 32-bit system. ... You can see the panic message here: http://imgur.com/s1lH15g. (there is no log and I have no serial console). There was some debug code in there when it hit

[PATCH] audit: Remove condition which always evaluates to false

always false [-Wtype-limits] if (s.backlog_wait_time < 0 || The following patch removes those unnecessary conditions. Signed-off-by: Pranith Kumar --- kernel/audit.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff

[PATCH] audit: Remove condition which always evaluates to false

-limits] if (s.backlog_wait_time 0 || The following patch removes those unnecessary conditions. Signed-off-by: Pranith Kumar bobby.pr...@gmail.com --- kernel/audit.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/kernel

Re: [RFC PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer

On Tue, Mar 3, 2015 at 9:34 AM, Catalin Marinas wrote: > > Do you mean the cmpxchg_double() change? Becuase %w0 and %0 is the same > physical register. You set it to 0 and immediately override it with > ldxp. > Thanks Catalin. I realized the blunder a while after Will pointed it out. The asm

Re: [RFC PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer

On Tue, Mar 3, 2015 at 9:34 AM, Catalin Marinas catalin.mari...@arm.com wrote: Do you mean the cmpxchg_double() change? Becuase %w0 and %0 is the same physical register. You set it to 0 and immediately override it with ldxp. Thanks Catalin. I realized the blunder a while after Will pointed

Re: [RFC PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer

On Fri, Feb 27, 2015 at 3:17 PM, Pranith Kumar wrote: > On Fri, Feb 27, 2015 at 3:15 PM, Will Deacon wrote: >>> @@ -166,11 +166,11 @@ static inline int __cmpxchg_double(volatile void >>> *ptr1, volatile void *ptr2, >>> VM_BUG_ON((unsigned long *)ptr

Re: [RFC PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer

On Fri, Feb 27, 2015 at 3:15 PM, Will Deacon wrote: > On Fri, Feb 27, 2015 at 08:09:17PM +0000, Pranith Kumar wrote: >> ARM64 documentation recommends keeping exclusive loads and stores as close as >> possible. Any instructions which do not depend on the value loaded should be &

[RFC PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer

instruction without any change in functionality. This patch does that change. Signed-off-by: Pranith Kumar --- arch/arm64/include/asm/cmpxchg.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h index cb95930

Re: [RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail

On Fri, Feb 27, 2015 at 2:08 PM, Mark Rutland wrote: > On Fri, Feb 27, 2015 at 06:44:19PM +0000, Pranith Kumar wrote: >> On Fri, Feb 27, 2015 at 1:33 PM, Catalin Marinas >> wrote: >> > It's either badly formatted or I don't get it. Are the "stxr x1" and >&g

Re: [RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail

On Fri, Feb 27, 2015 at 1:33 PM, Catalin Marinas wrote: > It's either badly formatted or I don't get it. Are the "stxr x1" and > "stxr x7" happening on the same CPU (P0)? If yes, that's badly written > code, not even architecturally compliant (you are not allowed other > memory accesses between

Re: [RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail

On Fri, Feb 27, 2015 at 5:06 AM, Will Deacon wrote: > On Fri, Feb 27, 2015 at 05:46:55AM +0000, Pranith Kumar wrote: >> In cmpxchg(), we do a load exclusive on an address and upon a comparison >> fail, >> we skip the store exclusive instruction. This can result in the exclu

Re: [RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail

On Fri, Feb 27, 2015 at 1:33 PM, Catalin Marinas catalin.mari...@arm.com wrote: It's either badly formatted or I don't get it. Are the stxr x1 and stxr x7 happening on the same CPU (P0)? If yes, that's badly written code, not even architecturally compliant (you are not allowed other memory

  1   2   3   4   5   6   7   8   9   10   >