linux-kernel - Re: [PATCH v2] fs: use acquire ordering in __fget

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]

Date:   Mon, 31 Oct 2022 18:48:25 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Jann Horn <jannh@...gle.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Miklos Szeredi <mszeredi@...hat.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Will Deacon <will@...nel.org>
Subject: Re: [PATCH v2] fs: use acquire ordering in __fget_light()

On Mon, Oct 31, 2022 at 07:13:30PM +0100, Jann Horn wrote:
> On Mon, Oct 31, 2022 at 7:08 PM Al Viro <viro@...iv.linux.org.uk> wrote:
> [...]
> > No arch-specific instances, so...
> > static __always_inline int
> > arch_atomic_read_acquire(const atomic_t *v)
> > {
> >         int ret;
> >
> >         if (__native_word(atomic_t)) {
> >                 ret = smp_load_acquire(&(v)->counter);
> >         } else {
> >                 ret = arch_atomic_read(v);
> >                 __atomic_acquire_fence();
> >         }
> >
> >         return ret;
> > }
> [...]
> > Do we really have any architectures where a structure with one
> > int field does *not* have a size that would satisfy that check?
> >
> > Is it future-proofing for masturbation sake, or am I missing something
> > real here?
> 
> include/linux/atomic/atomic-arch-fallback.h has a comment at the top that says:
> 
> // Generated by scripts/atomic/gen-atomic-fallback.sh
> // DO NOT MODIFY THIS FILE DIRECTLY

Hmm...  Apparently, the source is shared for atomic and atomic64, and the
check is intended for atomic64 counterpart of that thing on 32bit boxen.
Might make sense to put a comment in there...

The question about architectures with non-default implementations still
stands, though.

Anyway, it's unrelated to the patch itself.  I'm fine with it in the current
form.  Will apply for the next merge window, unless Linus wants it in right
now.