[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3f132208-12a2-4821-bf32-8c8569c632fc@paulmck-laptop>
Date: Sat, 4 May 2024 15:17:36 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.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 Sat, May 04, 2024 at 12:25:12PM -0700, Linus Torvalds wrote:
> On Sat, 4 May 2024 at 12:11, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > Anyway, the above are all normal optimizations that compilers
> > *already* do, and the only real issue is that with memory ordering,
> > the "dominance" thing will need to take into account the ordering
> > requirements of other memory operations with stricter memory ordering
> > in between. So, for example, if you have
> >
> > __atomic_store_n(ptr,1, RELAXED);
> > __atomic_load_n(otherptr,2, ACQUIRE);
> > __atomic_store_n(ptr,2, RELAXED);
I am assuming that I should ignore the "2," in that load.
> > then the second store doesn't dominate the first store, because
> > there's a stricter memory ordering instruction in between.
>
> Actually, that was a bad example, because in that pattern, the second
> store does actually dominate (the second store can not move up beyond
> the ACQUIRE, but the first store can indeed move down after it, so
> dominance analysis does actually allow the second store to strictly
> dominate the first one).
Agreed, and the stores can be combined as a result of the fact that
the two stores can be reordered to be adjacent to one another.
> So the ACQUIRE would need to be SEQ for my example to be valid.
And here the C and C++ memory models get very strange due to mixing
memory_order_seq_cst and non-memory_order_seq_cst.
But if there was a Linux-kernel smp_mb() immediately after that first
store, then the compiler would not be allowed to combine the two stores.
Though that is true regardless because of the smp_mb()'s barrier().
> Of course, usually the barrier that stops domination is something
> entirely different. Even without an actual conditional (which is
> almost certainly the most common reason why dominance goes away), it
> might be a function call (which could do any arbitrary memory ordering
> operations - there was a clang bug in this very case) or something
> like an explicit full memory barrier.
If there was something like, then the two stores could not be combined,
from what I can see.
__atomic_store_n(ptr,1, RELAXED);
__atomic_load_n(otherptr, ACQUIRE);
__atomic_store_n(otherptr, 4, RELEASE);
__atomic_store_n(ptr,2, RELAXED);
I freely confess that I don't know how to map that into dominance
relations, which means that I have no idea what this example means
in terms of your rules.
> Anyway, take that email as a "written in the MUA on the fly". There
> might be other thinkos in there. But I think the big picture was
> right.
If things go as they usually do, there will be quite a few litmus tests
between here and something credible. ;-)
Thank you for the tutorial on dominance in CFGs!
Thanx, Paul
Powered by blists - more mailing lists