[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [PATCH v3] tty: tty_io: remove hung_up_tty_fops
From:       "Paul E. McKenney" <paulmck () kernel ! org>
Date:       2024-05-04 22:17:36
Message-ID: 3f132208-12a2-4821-bf32-8c8569c632fc () paulmck-laptop
[Download RAW message or body]

On Sat, May 04, 2024 at 12:25:12PM -0700, Linus Torvalds wrote:
> On Sat, 4 May 2024 at 12:11, Linus Torvalds
> <torvalds@linux-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

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic