lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 17 Feb 2020 16:04:53 +0000
From:   Filipe Manana <>
To:     Linus Torvalds <>,
        Josef Bacik <>
Cc:     Dave Jones <>,
        David Sterba <>,
        Linux Kernel Mailing List <>
Subject: Re: Linux 5.6-rc2

On 17/02/20 05:08, Linus Torvalds wrote:
> On Sun, Feb 16, 2020 at 7:02 PM Josef Bacik <> wrote:
>> I assume Filipe wrote this based on my patch here
>> which makes it so we can allocate safely in this context, but that patch hasn't
>> made it's way to you yet.  Do you want it now?  It was prep for a much less safe
>> patchset, but is fine by itself.  Thanks,
> I assume it's either that, or revert 28553fa992cb and do it differently..
> I'll leave that whole decision to the btrfs people who actually know
> the code and the situations and what the alternative would look
> like...

So what happened was that the patch was developed against the
integration branch, where we don't use search paths in spinning mode
anymore - this was done by Josef's patch, which itself is not a bug fix
but it's necessary for another bug fix that is only on the integration

On 5.6-rcX and any other other older kernels we have the search using
spinning locks, that's why we run into this problem.

The solution can be either adding Josef's patch or changing the order in
which my patch unlocks the file range - to do it after the patch is
freed (which releases any spin locks it might be holding).

I've just sent a patch for that:

I'm fine with either solution.


>                Linus

Powered by blists - more mailing lists