Re: [RFC]: Possible race condition in kernel futex code

2016-05-15 Thread Ben Hutchings
On Fri, 2015-10-09 at 10:06 +0100, Thomas Gleixner wrote: [...] > @stable: Can you please pick up ff47ab4ff3cd plusĀ  > > df90ca969035d x86, sparse: Do not force removal of __user when calling > copy_to/from_user_nocheck() > > for stable kernels <= 3.12? [...] I've finally queued these up for

Re: [RFC]: Possible race condition in kernel futex code

2016-05-15 Thread Ben Hutchings
On Fri, 2015-10-09 at 10:06 +0100, Thomas Gleixner wrote: [...] > @stable: Can you please pick up ff47ab4ff3cd plusĀ  > > df90ca969035d x86, sparse: Do not force removal of __user when calling > copy_to/from_user_nocheck() > > for stable kernels <= 3.12? [...] I've finally queued these up for

Re: [RFC]: Possible race condition in kernel futex code

2015-10-17 Thread Greg KH
On Fri, Oct 09, 2015 at 10:06:41AM +0100, Thomas Gleixner wrote: > On Mon, 5 Oct 2015, Jaccon Bastiaansen wrote: > > We did some tests with different compilers, kernel versions and kernel > > configs, with the following results: > > > > Linux 3.12.48, x86_64_defconfig, GCC 4.6.1 : > >

Re: [RFC]: Possible race condition in kernel futex code

2015-10-17 Thread Greg KH
On Fri, Oct 09, 2015 at 10:06:41AM +0100, Thomas Gleixner wrote: > On Mon, 5 Oct 2015, Jaccon Bastiaansen wrote: > > We did some tests with different compilers, kernel versions and kernel > > configs, with the following results: > > > > Linux 3.12.48, x86_64_defconfig, GCC 4.6.1 : > >

Re: [RFC]: Possible race condition in kernel futex code

2015-10-09 Thread Peter Zijlstra
On Fri, Oct 09, 2015 at 11:25:09AM +0100, Thomas Gleixner wrote: > Hans, > > On Fri, 9 Oct 2015, Hans Zuidam wrote: > > On 9 okt. 2015, at 11:06, Thomas Gleixner wrote: > > > You cannot use an explicit 32bit read. We need an access which > > > handles the fault gracefully. > > > > The reason for

Re: [RFC]: Possible race condition in kernel futex code

2015-10-09 Thread Thomas Gleixner
Hans, On Fri, 9 Oct 2015, Hans Zuidam wrote: > On 9 okt. 2015, at 11:06, Thomas Gleixner wrote: > > You cannot use an explicit 32bit read. We need an access which > > handles the fault gracefully. > > The reason for the explicit read suggestion is to avoid the > _builtin_constant_p() in

Re: [RFC]: Possible race condition in kernel futex code

2015-10-09 Thread Hans Zuidam
Hi Thomas, On 9 okt. 2015, at 11:06, Thomas Gleixner wrote: On Mon, 5 Oct 2015, Jaccon Bastiaansen wrote: >> We did some tests with different compilers, kernel versions and kernel >> configs, with the following results: > You cannot use an explicit 32bit read. We need an access which handles

Re: [RFC]: Possible race condition in kernel futex code

2015-10-09 Thread Thomas Gleixner
On Mon, 5 Oct 2015, Jaccon Bastiaansen wrote: > We did some tests with different compilers, kernel versions and kernel > configs, with the following results: > > Linux 3.12.48, x86_64_defconfig, GCC 4.6.1 : > copy_user_generic_unrolled being used, so race condition possible > Linux 3.12.48,

Re: [RFC]: Possible race condition in kernel futex code

2015-10-09 Thread Thomas Gleixner
On Mon, 5 Oct 2015, Jaccon Bastiaansen wrote: > We did some tests with different compilers, kernel versions and kernel > configs, with the following results: > > Linux 3.12.48, x86_64_defconfig, GCC 4.6.1 : > copy_user_generic_unrolled being used, so race condition possible > Linux 3.12.48,

Re: [RFC]: Possible race condition in kernel futex code

2015-10-09 Thread Hans Zuidam
Hi Thomas, On 9 okt. 2015, at 11:06, Thomas Gleixner wrote: On Mon, 5 Oct 2015, Jaccon Bastiaansen wrote: >> We did some tests with different compilers, kernel versions and kernel >> configs, with the following results: > You cannot use an explicit 32bit read. We need an

Re: [RFC]: Possible race condition in kernel futex code

2015-10-09 Thread Thomas Gleixner
Hans, On Fri, 9 Oct 2015, Hans Zuidam wrote: > On 9 okt. 2015, at 11:06, Thomas Gleixner wrote: > > You cannot use an explicit 32bit read. We need an access which > > handles the fault gracefully. > > The reason for the explicit read suggestion is to avoid the >

Re: [RFC]: Possible race condition in kernel futex code

2015-10-09 Thread Peter Zijlstra
On Fri, Oct 09, 2015 at 11:25:09AM +0100, Thomas Gleixner wrote: > Hans, > > On Fri, 9 Oct 2015, Hans Zuidam wrote: > > On 9 okt. 2015, at 11:06, Thomas Gleixner wrote: > > > You cannot use an explicit 32bit read. We need an access which > > > handles the fault gracefully. >

[RFC]: Possible race condition in kernel futex code

2015-10-05 Thread Jaccon Bastiaansen
Hello all, For a while now, we see our application crashing occasionally (due to an assert) in the middle of a pthread_mutex_lock() function call. To be more precise, our application is threaded (50 threads) where all threads share a custom memory allocator. This memory allocator is guarded with

[RFC]: Possible race condition in kernel futex code

2015-10-05 Thread Jaccon Bastiaansen
Hello all, For a while now, we see our application crashing occasionally (due to an assert) in the middle of a pthread_mutex_lock() function call. To be more precise, our application is threaded (50 threads) where all threads share a custom memory allocator. This memory allocator is guarded with