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:03PM +
...@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
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 partitio
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
kernel between the systemd-udevd and iscsi-logout processing as described
Since 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
, 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
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
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,
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 3.
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 :
> > copy_user_ge
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
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 __copy_fr
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 the
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, x86_64
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
15 matches
Mail list logo
