[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wg4iAjQb_Na_1rf_EHxe7rsN24he6cjKgdOAPmn7N9oVw@mail.gmail.com>
Date: Fri, 3 May 2024 17:14:22 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: paulmck@...nel.org
Cc: Boqun Feng <boqun.feng@...il.com>, Marco Elver <elver@...gle.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Dmitry Vyukov <dvyukov@...gle.com>,
syzbot <syzbot+b7c3ba8cdc2f6cf83c21@...kaller.appspotmail.com>,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
Nathan Chancellor <nathan@...nel.org>, Arnd Bergmann <arnd@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
Jiri Slaby <jirislaby@...nel.org>
Subject: Re: [PATCH v3] tty: tty_io: remove hung_up_tty_fops
On Fri, 3 May 2024 at 16:59, Paul E. McKenney <paulmck@...nel.org> wrote:
>
> Hmmm... Maybe something like this very lightly tested patch?
I'm a bit nervous about using the built-in atomics, when it's not
clear what the compiler will do on various architectures.
Gcc documentation talks about __atomic_is_lock_free(), which makes me
think that on various architectures it might end up doing some "fall
back to helper functions" cases (possibly for odd architectures).
IOW: I don't think the patch is wrong, but I do think we need to
verify that all compilers we support generate the obvious code for
this, and we don't have some "fall back to function calls".
Linus
Powered by blists - more mailing lists