linux-kernel - Re: [PATCH] btrfs: optimize barrier usage for Rmw atomics

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <20200129192550.nnfkkgde445nrbko@linux-p48b>
Date:   Wed, 29 Jan 2020 11:25:50 -0800
From:   Davidlohr Bueso <dave@...olabs.net>
To:     dsterba@...e.cz, dsterba@...e.com, nborisov@...e.com,
        linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH] btrfs: optimize barrier usage for Rmw atomics

On Wed, 29 Jan 2020, David Sterba wrote:

>On Wed, Jan 29, 2020 at 10:03:24AM -0800, Davidlohr Bueso wrote:
>> Use smp_mb__after_atomic() instead of smp_mb() and avoid the
>> unnecessary barrier for non LL/SC architectures, such as x86.
>
>So that's a conflicting advice from what we got when discussing wich
>barriers to use in 6282675e6708ec78518cc0e9ad1f1f73d7c5c53d and the
>memory is still fresh. My first idea was to take the
>smp_mb__after_atomic and __before_atomic variants and after discussion
>with various people the plain smp_wmb/smp_rmb were suggested and used in
>the end.

So the patch you mention deals with test_bit(), which is out of the scope
of smp_mb__{before,after}_atomic() as it's not a RMW operation. atomic_inc()
and set_bit() are, however, meant to use these barriers.

>
>I can dig the email threads and excerpts from irc conversations, maybe
>Nik has them at hand too. We do want to get rid of all unnecessary and
>uncommented barriers in btrfs code, so I appreciate your patch.

Yeah, I struggled with the amount of undocumented barriers, and decided
not to go down that rabbit hole. This patch is only an equivalent of
what is currently there. When possible, getting rid of barriers is of
course better.

Thanks,
Davidlohr