Re: Race condition in Kernel

nt: Thursday, March 25, 2021 7:16 AM > To: Gulam Mohamed > Cc: h...@infradead.org; linux-kernel@vger.kernel.org; > linux-bl...@vger.kernel.org; Junxiao Bi ; Martin > Petersen ; ax...@kernel.dk > Subject: Re: Race condition in Kernel > > On Wed, Mar 24, 2021 at 12:37:03

RE: Race condition in Kernel

...@vger.kernel.org; Junxiao Bi ; Martin Petersen ; ax...@kernel.dk Subject: Re: Race condition in Kernel On Wed, Mar 24, 2021 at 12:37:03PM +, Gulam Mohamed wrote: > Hi All, > > We are facing a stale link (of the device) issue during the iscsi-logout > process if we use parted

Re: Race condition in Kernel

On Wed, Mar 24, 2021 at 12:37:03PM +, Gulam Mohamed wrote: > Hi All, > > We are facing a stale link (of the device) issue during the iscsi-logout > process if we use parted command just before the iscsi logout. Here are the > details: > > As part of iscsi logout, the

Re: Race condition in Kernel

/devices/platform/hostx/sessionx/targetx:x:x:x/x:x:x:x/block/sdb/sdb1 and since sdb is already removed, the symlink /sys/class/block/sdb1 will be orphan and stale. So, this stale link is a result of the race condition in kernel between the systemd-udevd and iscsi-logout processing as described above

Re: Race condition in Kernel

the symlink /sys/class/block/sdb1 points to > /sys/class/devices/platform/hostx/sessionx/targetx:x:x:x/x:x:x:x/block/sdb/sdb1 > and since sdb is already removed, the symlink /sys/class/block/sdb1 will be > orphan and stale. So, this stale link is a result of the race condition in

Race condition in Kernel

, the symlink /sys/class/block/sdb1 will be orphan and stale. So, this stale link is a result of the race condition in kernel between the systemd-udevd and iscsi-logout processing as described above. We are able to reproduce this even with latest upstream kernel. We have come across a patch

[PATCH AUTOSEL 5.6 223/606] net/tls: fix race condition causing kernel panic

From: Vinay Kumar Yadav [ Upstream commit 0cada33241d9de205522e3858b18e506ca5cce2c ] tls_sw_recvmsg() and tls_decrypt_done() can be run concurrently. // tls_sw_recvmsg() if (atomic_read(>decrypt_pending)) crypto_wait_req(-EINPROGRESS, >async_wait); else

[PATCH 5.4 015/142] net/tls: fix race condition causing kernel panic

From: Vinay Kumar Yadav [ Upstream commit 0cada33241d9de205522e3858b18e506ca5cce2c ] tls_sw_recvmsg() and tls_decrypt_done() can be run concurrently. // tls_sw_recvmsg() if (atomic_read(>decrypt_pending)) crypto_wait_req(-EINPROGRESS, >async_wait); else

[PATCH 5.6 017/177] net/tls: fix race condition causing kernel panic

From: Vinay Kumar Yadav [ Upstream commit 0cada33241d9de205522e3858b18e506ca5cce2c ] tls_sw_recvmsg() and tls_decrypt_done() can be run concurrently. // tls_sw_recvmsg() if (atomic_read(>decrypt_pending)) crypto_wait_req(-EINPROGRESS, >async_wait); else

Re: race condition in kernel/padata.c

On Thu, Mar 23, 2017 at 12:03:43AM +0100, Jason A. Donenfeld wrote: > Hey Steffen, > > WireGuard makes really heavy use of padata, feeding it units of work > from different cores in different contexts all at the same time. For > the most part, everything has been fine, but one particular user has

Re: race condition in kernel/padata.c

On Thu, Mar 23, 2017 at 12:03:43AM +0100, Jason A. Donenfeld wrote: > Hey Steffen, > > WireGuard makes really heavy use of padata, feeding it units of work > from different cores in different contexts all at the same time. For > the most part, everything has been fine, but one particular user has

race condition in kernel/padata.c

Hey Steffen, WireGuard makes really heavy use of padata, feeding it units of work from different cores in different contexts all at the same time. For the most part, everything has been fine, but one particular user has consistently run into mysterious bugs. He's using a rather old dual core CPU,

race condition in kernel/padata.c

Hey Steffen, WireGuard makes really heavy use of padata, feeding it units of work from different cores in different contexts all at the same time. For the most part, everything has been fine, but one particular user has consistently run into mysterious bugs. He's using a rather old dual core CPU,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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