On Fri, Feb 27, 2015 at 5:06 AM, Will Deacon will.dea...@arm.com wrote:
On Fri, Feb 27, 2015 at 05:46:55AM +, 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 exclusive bit
On Fri, Feb 27, 2015 at 3:17 PM, Pranith Kumar bobby.pr...@gmail.com wrote:
On Fri, Feb 27, 2015 at 3:15 PM, Will Deacon will.dea...@arm.com wrote:
@@ -166,11 +166,11 @@ static inline int __cmpxchg_double(volatile void
*ptr1, volatile void *ptr2,
VM_BUG_ON((unsigned long *)ptr2
instruction without any change in
functionality. This patch does that change.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
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
On Fri, Feb 27, 2015 at 3:15 PM, Will Deacon will.dea...@arm.com wrote:
On Fri, Feb 27, 2015 at 08:09:17PM +, 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
On Fri, Feb 27, 2015 at 2:08 PM, Mark Rutland mark.rutl...@arm.com wrote:
On Fri, Feb 27, 2015 at 06:44:19PM +, Pranith Kumar wrote:
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
need to clear the exclusive bit in these cases.
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..ed2cf90 100644
need to clear the exclusive bit in these cases.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
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
On Wed, Feb 25, 2015 at 11:21 AM, Arnd Bergmann wrote:
>>
>> More information:
>> [ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
>> [ 45.833324] [ cut here ]
>> [ 45.837939] kernel BUG at
>>
On Wed, Feb 25, 2015 at 12:14 PM, Russell King - ARM Linux
wrote:
> Actually, I think we ought to get rid of __bad_xchg() so that cases
> like this cause a link error instead of a runtime error, just like we
> do in other cases as well.
>
> That's something that goes back ages (it used to be
On Wed, Feb 25, 2015 at 12:02 PM, Russell King - ARM Linux
wrote:
>> Unfortunately, the BUG message seems incomplete, can you reproduce this
>> with CONFIG_DEBUG_BUGVERBOSE enabled?
>
> That isn't because CONFIG_DEBUG_BUGVERBOSE isn't set. It's because
> the message author decided that the
On Wed, Feb 25, 2015 at 10:58 AM, Arnd Bergmann wrote:
> On Wednesday 25 February 2015 10:36:20 Pranith Kumar wrote:
>> This patch adds support for a half-word xchg() for ARM using ldrexh/strexh
>> instructions. It also fixes an asm comment for __cmpxchg2.
>>
>> Curre
[ 45.833324] [ cut here ]
[ 45.837939] kernel BUG at
/dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
Signed-off-by: Pranith Kumar
---
arch/arm/include/asm/cmpxchg.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff
[ 45.833324] [ cut here ]
[ 45.837939] kernel BUG at
/dvs/git/dirty/git-master_linux/kernel/arch/arm/kernel/traps.c:727!
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
arch/arm/include/asm/cmpxchg.h | 18 +-
1 file changed, 17 insertions(+), 1
On Wed, Feb 25, 2015 at 10:58 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 25 February 2015 10:36:20 Pranith Kumar wrote:
This patch adds support for a half-word xchg() for ARM using ldrexh/strexh
instructions. It also fixes an asm comment for __cmpxchg2.
Currently using a half-word
On Wed, Feb 25, 2015 at 12:02 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Unfortunately, the BUG message seems incomplete, can you reproduce this
with CONFIG_DEBUG_BUGVERBOSE enabled?
That isn't because CONFIG_DEBUG_BUGVERBOSE isn't set. It's because
the message author decided
On Wed, Feb 25, 2015 at 11:21 AM, Arnd Bergmann a...@arndb.de wrote:
More information:
[ 45.833303] xchg: bad data size: pc 0xbe806020, ptr 0xeb18deee, size 2
[ 45.833324] [ cut here ]
[ 45.837939] kernel BUG at
On Wed, Feb 25, 2015 at 12:14 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Actually, I think we ought to get rid of __bad_xchg() so that cases
like this cause a link error instead of a runtime error, just like we
do in other cases as well.
That's something that goes back ages
Hi Mathieu,
On Thu, Feb 5, 2015 at 10:06 PM, Mathieu Desnoyers
wrote:
> A smp_read_barrier_depends() appears to be missing in llist_del_first().
> It should only matter for Alpha in practice. Adding it after the check
> of entry against NULL allows skipping the barrier in a common case.
We
Hi Mathieu,
On Thu, Feb 5, 2015 at 10:06 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
A smp_read_barrier_depends() appears to be missing in llist_del_first().
It should only matter for Alpha in practice. Adding it after the check
of entry against NULL allows skipping the barrier
On Thu, Jan 22, 2015 at 5:35 PM, Stewart Smith
wrote:
> Pranith Kumar writes:
>> On Thu, Jan 22, 2015 at 12:19 AM, Michael Ellerman
>> wrote:
>>> On Wed, 2015-01-21 at 21:26 -0500, Pranith Kumar wrote:
>>>> When CONFIG_PRINTK=n, log_buf_addr_get() returns NU
On Thu, Jan 22, 2015 at 12:19 AM, Michael Ellerman wrote:
> On Wed, 2015-01-21 at 21:26 -0500, Pranith Kumar wrote:
>> When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get()
>> return 0. Check for these return values and skip registering the dump buffer.
&
On Thu, Jan 22, 2015 at 12:19 AM, Michael Ellerman m...@ellerman.id.au wrote:
On Wed, 2015-01-21 at 21:26 -0500, Pranith Kumar wrote:
When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get()
return 0. Check for these return values and skip registering the dump buffer
On Thu, Jan 22, 2015 at 5:35 PM, Stewart Smith
stew...@linux.vnet.ibm.com wrote:
Pranith Kumar bobby.pr...@gmail.com writes:
On Thu, Jan 22, 2015 at 12:19 AM, Michael Ellerman m...@ellerman.id.au
wrote:
On Wed, 2015-01-21 at 21:26 -0500, Pranith Kumar wrote:
When CONFIG_PRINTK=n
When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get()
return 0. Check for these return values and skip registering the dump buffer.
Signed-off-by: Pranith Kumar
CC: Michael Ellerman
---
arch/powerpc/platforms/powernv/opal.c | 6 ++
1 file changed, 6 insertions
There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
for when CONFIG_PRINTK is not set causing build failures.
This patch adds these dummy routines at the appropriate location.
Signed-off-by: Pranith Kumar
CC: Michael Ellerman
---
include/linux/printk.h | 15
On Wed, Jan 21, 2015 at 7:58 AM, Petr Mladek wrote:
> On Tue 2015-01-20 18:51:49, Pranith Kumar wrote:
>> There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
>> for when CONFIG_PRINTK is not set causing build failures.
>>
>> This patc
On Wed, Jan 21, 2015 at 7:58 AM, Petr Mladek pmla...@suse.cz wrote:
On Tue 2015-01-20 18:51:49, Pranith Kumar wrote:
There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
for when CONFIG_PRINTK is not set causing build failures.
This patch adds these dummy routines
There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
for when CONFIG_PRINTK is not set causing build failures.
This patch adds these dummy routines at the appropriate location.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Michael Ellerman m...@ellerman.id.au
When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get()
return 0. Check for these return values and skip registering the dump buffer.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Michael Ellerman m...@ellerman.id.au
---
arch/powerpc/platforms/powernv/opal.c | 6
When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get()
return 0. Check for these return values and skip registering the dump buffer.
Signed-off-by: Pranith Kumar
CC: Michael Ellerman
---
arch/powerpc/platforms/powernv/opal.c | 6 ++
1 file changed, 6 insertions
There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
for when CONFIG_PRINTK is not set causing build failures.
This patch adds these dummy routines at the appropriate location.
Signed-off-by: Pranith Kumar
CC: Michael Ellerman
---
include/linux/printk.h | 15
When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get()
return 0. Check for these return values and skip registering the dump buffer.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Michael Ellerman m...@ellerman.id.au
---
arch/powerpc/platforms/powernv/opal.c | 6
There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
for when CONFIG_PRINTK is not set causing build failures.
This patch adds these dummy routines at the appropriate location.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Michael Ellerman m...@ellerman.id.au
On Tue, Dec 30, 2014 at 1:50 PM, Peter Zijlstra wrote:
> On Tue, Dec 30, 2014 at 12:46:22AM -0500, Pranith Kumar wrote:
>> Isolate the SRCU functions and data structures within CONFIG_SRCU so that
>> there
>> is a compile time failure if srcu is used when not enab
On Tue, Dec 30, 2014 at 1:50 PM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Dec 30, 2014 at 12:46:22AM -0500, Pranith Kumar wrote:
Isolate the SRCU functions and data structures within CONFIG_SRCU so that
there
is a compile time failure if srcu is used when not enabled
On Mon, Dec 29, 2014 at 4:01 AM, Michael Ellerman wrote:
> On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote:
>> In an allnoconfig we get the following build failure:
>
> An allnoconfig doesn't include CONFIG_PPC_POWERNV? But I think I know what you
> mean.
>
>> a
-off-by: Pranith Kumar
Reported-by: Scott Wood
---
lib/assoc_array.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/assoc_array.c b/lib/assoc_array.c
index 2404d03..03dd576 100644
--- a/lib/assoc_array.c
+++ b/lib/assoc_array.c
@@ -11,6 +11,7 @@
* 2 of the Licence, or (at your option
.
Signed-off-by: Pranith Kumar
CC: Scott Wood
---
v2:
- fix build failures reported by Scott Wood
arch/powerpc/kernel/setup_64.c | 7 ++-
arch/powerpc/kernel/smp.c | 9 +++-
arch/s390/kernel/asm-offsets.c | 7 ++-
include/linux/notifier.h | 47
On Mon, Dec 29, 2014 at 6:05 PM, Scott Wood wrote:
> On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote:
>> Isolate the SRCU functions and data structures within CONFIG_SRCU so that
>> there
>> is a compile time failure if srcu is used when not enabled. This was decide
On Mon, Dec 29, 2014 at 5:03 AM, Martin Schwidefsky
wrote:
> On Sat, 27 Dec 2014 12:17:43 -0500
> Pranith Kumar wrote:
>
>> @@ -65,10 +65,13 @@
>> #include
>> #include
>> #include
>> -#include
>> #include
>> #include
>>
On Mon, Dec 29, 2014 at 5:03 AM, Martin Schwidefsky
schwidef...@de.ibm.com wrote:
On Sat, 27 Dec 2014 12:17:43 -0500
Pranith Kumar bobby.pr...@gmail.com wrote:
@@ -65,10 +65,13 @@
#include asm/kexec.h
#include asm/mmu_context.h
#include asm/code-patching.h
-#include asm/kvm_ppc.h
On Mon, Dec 29, 2014 at 6:05 PM, Scott Wood scottw...@freescale.com wrote:
On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote:
Isolate the SRCU functions and data structures within CONFIG_SRCU so that
there
is a compile time failure if srcu is used when not enabled. This was decided
.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Scott Wood scottw...@freescale.com
---
v2:
- fix build failures reported by Scott Wood
arch/powerpc/kernel/setup_64.c | 7 ++-
arch/powerpc/kernel/smp.c | 9 +++-
arch/s390/kernel/asm-offsets.c | 7 ++-
include/linux
-off-by: Pranith Kumar bobby.pr...@gmail.com
Reported-by: Scott Wood scottw...@freescale.com
---
lib/assoc_array.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/assoc_array.c b/lib/assoc_array.c
index 2404d03..03dd576 100644
--- a/lib/assoc_array.c
+++ b/lib/assoc_array.c
@@ -11,6 +11,7
On Mon, Dec 29, 2014 at 4:01 AM, Michael Ellerman m...@ellerman.id.au wrote:
On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote:
In an allnoconfig we get the following build failure:
An allnoconfig doesn't include CONFIG_PPC_POWERNV? But I think I know what you
mean.
arch/powerpc
On Sat, Dec 27, 2014 at 11:24 AM, Pranith Kumar wrote:
> On Fri, Dec 26, 2014 at 11:54 AM, Paul E. McKenney wrote:
>> Pranith, if Stephen has CONFIG_KVM=n, it might be best to move the
>> "select SRCU" to "config PPC" in arch/powerpc/Kconfig. Are you able
>&
.
Signed-off-by: Pranith Kumar
---
arch/powerpc/kernel/setup_64.c | 7 ++-
arch/s390/kernel/asm-offsets.c | 7 ++-
include/linux/notifier.h | 47 --
include/linux/srcu.h | 6 +-
4 files changed, 44 insertions(+), 23 deletions
: *** [vmlinux] Error 1
This happens because powernv requires printk() support. Enable it in the config
file.
Signed-off-by: Pranith Kumar
---
arch/powerpc/platforms/powernv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/powernv/Kconfig
b/arch/powerpc/platforms/powernv
On Fri, Dec 26, 2014 at 11:54 AM, Paul E. McKenney wrote:
> Pranith, if Stephen has CONFIG_KVM=n, it might be best to move the
> "select SRCU" to "config PPC" in arch/powerpc/Kconfig. Are you able
> to cross-build powerpc?
>
ppc 32 seems fine without selecting srcu unconditionally. So I added
On Fri, Dec 26, 2014 at 11:54 AM, Paul E. McKenney wrote:
Pranith, if Stephen has CONFIG_KVM=n, it might be best to move the
select SRCU to config PPC in arch/powerpc/Kconfig. Are you able
to cross-build powerpc?
ppc 32 seems fine without selecting srcu unconditionally. So I added
this
.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
arch/powerpc/kernel/setup_64.c | 7 ++-
arch/s390/kernel/asm-offsets.c | 7 ++-
include/linux/notifier.h | 47 --
include/linux/srcu.h | 6 +-
4 files changed, 44 insertions
: *** [vmlinux] Error 1
This happens because powernv requires printk() support. Enable it in the config
file.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
arch/powerpc/platforms/powernv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/powernv/Kconfig
b/arch
On Sat, Dec 27, 2014 at 11:24 AM, Pranith Kumar bobby.pr...@gmail.com wrote:
On Fri, Dec 26, 2014 at 11:54 AM, Paul E. McKenney wrote:
Pranith, if Stephen has CONFIG_KVM=n, it might be best to move the
select SRCU to config PPC in arch/powerpc/Kconfig. Are you able
to cross-build powerpc
, '...',
0)... [OK]
Tested on a 32-bit powerpc system.
Signed-off-by: Pranith Kumar
---
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/asm/unistd.h | 2 +-
arch/powerpc/include/uapi/asm/unistd.h | 1 +
3 files changed, 3 insertions(+), 1
On Sun, Dec 21, 2014 at 4:56 AM, Stephen Rothwell wrote:
> Hi Pranith,
>
> On Sat, 20 Dec 2014 11:47:18 -0500 Pranith Kumar
> wrote:
>>
>> Wire up sys_execveat(). This passes the selftests for the system call.
>
> Thanks for this, but ...
>
>> diff --
On Sun, Dec 21, 2014 at 4:56 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Pranith,
On Sat, 20 Dec 2014 11:47:18 -0500 Pranith Kumar bobby.pr...@gmail.com
wrote:
Wire up sys_execveat(). This passes the selftests for the system call.
Thanks for this, but ...
diff --git a/arch
, '...',
0)... [OK]
Tested on a 32-bit powerpc system.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/asm/unistd.h | 2 +-
arch/powerpc/include/uapi/asm/unistd.h | 1 +
3 files changed, 3
, '...',
0)... [OK]
Tested on a 32-bit powerpc system.
Signed-off-by: Pranith Kumar
---
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/asm/unistd.h | 2 +-
arch/powerpc/include/uapi/asm/unistd.h | 1 +
3 files changed, 3 insertions(+), 1
, '...',
0)... [OK]
Tested on a 32-bit powerpc system.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/asm/unistd.h | 2 +-
arch/powerpc/include/uapi/asm/unistd.h | 1 +
3 files changed, 3
On 12/10/2014 03:09 AM, Stephen Rothwell wrote:
> Hi Paul,
>
> After merging the rcu tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
>
> In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
> from arch/powerpc/kernel/setup_64.c:68:
>
On 12/10/2014 03:09 AM, Stephen Rothwell wrote:
Hi Paul,
After merging the rcu tree, today's linux-next build (powerpc64
allnoconfig) failed like this:
In file included from arch/powerpc/include/asm/kvm_ppc.h:30:0,
from arch/powerpc/kernel/setup_64.c:68:
zalloc_cpumask_var() can return 0 on allocation failure when
CONFIG_CPUMASK_OFFSTACK is set. Check for the return value and warn on failure
of an allocation in such cases. Also remove the cpus from cpu masks so
that they are not accessed later on.
Signed-off-by: Pranith Kumar
---
arch/x86
On Tue, Dec 9, 2014 at 3:10 PM, Thomas Gleixner wrote:
> On Tue, 9 Dec 2014, Pranith Kumar wrote:
>> zalloc_cpumask_var() can return 0 on allocation failure when
>> CONFIG_CPUMASK_OFFSTACK is set. Check for the return value and WARN() on
>> failure
>> of
. This
prevents build failures as KVM is dependent on SRCU.
Signed-off-by: Pranith Kumar
CC: Paul E. McKenney
CC: Josh Triplett
CC: Lai Jiangshan
Signed-off-by: Paul E. McKenney
---
arch/s390/kernel/asm-offsets.c | 7 ++-
include/linux/notifier.h | 47
zalloc_cpumask_var() can return 0 on allocation failure when
CONFIG_CPUMASK_OFFSTACK is set. Check for the return value and WARN() on failure
of an allocation in such cases.
Signed-off-by: Pranith Kumar
---
arch/x86/kernel/smpboot.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions
. This
prevents build failures as KVM is dependent on SRCU.
Signed-off-by: Pranith Kumar
Acked-by: Christian Borntraeger [for s390 parts]
CC: Josh Triplett
CC: Lai Jiangshan
CC: Paul E. McKenney
---
arch/s390/kernel/asm-offsets.c | 7 ++-
include/linux/notifier.h | 47
. This
prevents build failures as KVM is dependent on SRCU.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
Acked-by: Christian Borntraeger borntrae...@de.ibm.com [for s390 parts]
CC: Josh Triplett j...@joshtriplett.org
CC: Lai Jiangshan la...@cn.fujitsu.com
CC: Paul E. McKenney paul
zalloc_cpumask_var() can return 0 on allocation failure when
CONFIG_CPUMASK_OFFSTACK is set. Check for the return value and WARN() on failure
of an allocation in such cases.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
arch/x86/kernel/smpboot.c | 10 +++---
1 file changed, 7
. This
prevents build failures as KVM is dependent on SRCU.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Paul E. McKenney paul...@linux.vnet.ibm.com
CC: Josh Triplett j...@joshtriplett.org
CC: Lai Jiangshan la...@cn.fujitsu.com
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
On Tue, Dec 9, 2014 at 3:10 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 9 Dec 2014, Pranith Kumar wrote:
zalloc_cpumask_var() can return 0 on allocation failure when
CONFIG_CPUMASK_OFFSTACK is set. Check for the return value and WARN() on
failure
of an allocation in such cases
zalloc_cpumask_var() can return 0 on allocation failure when
CONFIG_CPUMASK_OFFSTACK is set. Check for the return value and warn on failure
of an allocation in such cases. Also remove the cpus from cpu masks so
that they are not accessed later on.
Signed-off-by: Pranith Kumar bobby.pr
On Mon, Dec 8, 2014 at 6:59 PM, Paul E. McKenney
wrote:
> On Mon, Dec 08, 2014 at 03:24:35PM -0500, Pranith Kumar wrote:
>> KVM uses srcu structures because of which CONFIG_KVM selects CONFIG_SRCU. In
>> asm-offsets.c, we are including kvm_host.h unconditionally even thoug
Signed-off-by: Pranith Kumar
---
arch/s390/kernel/asm-offsets.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c
index ef279a1..055334d 100644
--- a/arch/s390/kernel/asm-offsets.c
+++ b/arch/s390/kernel/a
Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
is a compile time failure if srcu is used when not enabled. This was decided to
be better than waiting until link time for a failure to occur.
Signed-off-by: Pranith Kumar
CC: Paul E. McKenney
CC: Josh Triplett
CC
Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
is a compile time failure if srcu is used when not enabled. This was decided to
be better than waiting until link time for a failure to occur.
Signed-off-by: Pranith Kumar
CC: Paul E. McKenney
CC: Josh Triplett
CC
Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
is a compile time failure if srcu is used when not enabled. This was decided to
be better than waiting until link time for a failure to occur.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Paul E. McKenney
Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
is a compile time failure if srcu is used when not enabled. This was decided to
be better than waiting until link time for a failure to occur.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Paul E. McKenney
-by: Pranith Kumar bobby.pr...@gmail.com
---
arch/s390/kernel/asm-offsets.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c
index ef279a1..055334d 100644
--- a/arch/s390/kernel/asm-offsets.c
+++ b/arch/s390/kernel
On Mon, Dec 8, 2014 at 6:59 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Mon, Dec 08, 2014 at 03:24:35PM -0500, Pranith Kumar wrote:
KVM uses srcu structures because of which CONFIG_KVM selects CONFIG_SRCU. In
asm-offsets.c, we are including kvm_host.h unconditionally even though
On Thu, Dec 4, 2014 at 9:05 PM, Lai Jiangshan wrote:
> On 12/05/2014 08:11 AM, Paul E. McKenney wrote:
>> On Thu, Dec 04, 2014 at 06:50:24PM -0500, Pranith Kumar wrote:
>>> SRCU is not necessary to be compiled by default in all cases. For
>>> tinification
>>&g
831552 64180 23944 919676 e087c arch/powerpc/boot/zImage : before
829504 64180 23952 917636 e0084 arch/powerpc/boot/zImage : after
so the savings are about ~2000 bytes.
Signed-off-by: Pranith Kumar
CC: Paul McKenney
CC: Josh Triplett
---
arch/arm/kvm/Kconfig | 1 +
arch/arm64
(resending, forgot CC's)
On Thu, Dec 4, 2014 at 11:13 AM, Josh Triplett wrote:
>>
>> The current tinyconfig on x86 enables SRCU by default since x86 enables
>> PERF_EVENTS which in-turn require SRCU support. If we disable
>> PERF_EVENTS, we can disable compiling SRCU for tiny configs on x86
On 12/04/2014 01:27 AM, Paul E. McKenney wrote:
> For the moment, I applied this to -rcu against v3.18-rc6 to get some 0day
> testing on it.
>
> There are conflicts against the tip of my tree, but will worry about
> that later. I don't have a ready answer on whether or not this needs
> to be
On 12/04/2014 01:27 AM, Paul E. McKenney wrote:
For the moment, I applied this to -rcu against v3.18-rc6 to get some 0day
testing on it.
There are conflicts against the tip of my tree, but will worry about
that later. I don't have a ready answer on whether or not this needs
to be split up
(resending, forgot CC's)
On Thu, Dec 4, 2014 at 11:13 AM, Josh Triplett j...@joshtriplett.org wrote:
The current tinyconfig on x86 enables SRCU by default since x86 enables
PERF_EVENTS which in-turn require SRCU support. If we disable
PERF_EVENTS, we can disable compiling SRCU for tiny
831552 64180 23944 919676 e087c arch/powerpc/boot/zImage : before
829504 64180 23952 917636 e0084 arch/powerpc/boot/zImage : after
so the savings are about ~2000 bytes.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Paul McKenney paul...@linux.vnet.ibm.com
CC: Josh Triplett j
On Thu, Dec 4, 2014 at 9:05 PM, Lai Jiangshan la...@cn.fujitsu.com wrote:
On 12/05/2014 08:11 AM, Paul E. McKenney wrote:
On Thu, Dec 04, 2014 at 06:50:24PM -0500, Pranith Kumar wrote:
SRCU is not necessary to be compiled by default in all cases. For
tinification
efforts not compiling SRCU
tested this using randconfig and building about 15 kernels. This is definitely
not complete and could use more testing. Sticking it in next might help in that
regards.
Comments and suggestions are welcome. Please let me know if I should split up
this patch.
Signed-off-by: Pranith Kumar
CC: Paul
On Wed, Dec 3, 2014 at 8:54 PM, Pranith Kumar wrote:
> (CC list restricted since this is just for initial feedback)
>
> SRCU is not necessary to be compiled by default in all cases. For tinification
> efforts not compiling SRCU unless necessary is desirable.
>
> The current p
tested this using randconfig and building about 15 kernels. This is definitely
not complete and could use more testing. Sticking it in next might help in that
regards.
Comments and suggestions are welcome. Please let me know if I should split
up this patch.
Signed-off-by: Pranith Kumar
CC: Paul
tested this using randconfig and building about 15 kernels. This is definitely
not complete and could use more testing. Sticking it in next might help in that
regards.
Comments and suggestions are welcome. Please let me know if I should split
up this patch.
Signed-off-by: Pranith Kumar
CC: Paul
tested this using randconfig and building about 15 kernels. This is definitely
not complete and could use more testing. Sticking it in next might help in that
regards.
Comments and suggestions are welcome. Please let me know if I should split
up this patch.
Signed-off-by: Pranith Kumar bobby.pr
tested this using randconfig and building about 15 kernels. This is definitely
not complete and could use more testing. Sticking it in next might help in that
regards.
Comments and suggestions are welcome. Please let me know if I should split
up this patch.
Signed-off-by: Pranith Kumar bobby.pr
On Wed, Dec 3, 2014 at 8:54 PM, Pranith Kumar bobby.pr...@gmail.com wrote:
(CC list restricted since this is just for initial feedback)
SRCU is not necessary to be compiled by default in all cases. For tinification
efforts not compiling SRCU unless necessary is desirable.
The current patch
tested this using randconfig and building about 15 kernels. This is definitely
not complete and could use more testing. Sticking it in next might help in that
regards.
Comments and suggestions are welcome. Please let me know if I should split up
this patch.
Signed-off-by: Pranith Kumar bobby.pr
On Wed, Nov 26, 2014 at 11:57 AM, Pranith Kumar wrote:
> set_mb() and smp_store_release() perform the same function. Also there are
> only
> a few users of set_mb(). We can convert these users to use smp_store_release()
> and delete the set_mb() definition.
>
> The follo
On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval wrote:
> The rcu_string API introduced some new sparse errors but also revealed
> existing
> ones. First of all, the name in struct btrfs_device should be annotated as
> __rcu to prevent unsafe reads. Additionally, updates should go through
>
On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval wrote:
> A naked read of the value of an RCU pointer isn't safe. Put the whole access
> in
> an RCU critical section, not just the pointer dereference.
>
> Signed-off-by: Omar Sandoval
You can use rcu_access_pointer() in the if() condition check
On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval osan...@osandov.com wrote:
A naked read of the value of an RCU pointer isn't safe. Put the whole access
in
an RCU critical section, not just the pointer dereference.
Signed-off-by: Omar Sandoval osan...@osandov.com
You can use
On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval osan...@osandov.com wrote:
The rcu_string API introduced some new sparse errors but also revealed
existing
ones. First of all, the name in struct btrfs_device should be annotated as
__rcu to prevent unsafe reads. Additionally, updates should go
101 - 200 of 984 matches
Mail list logo
