On Tue, 28 May 2024 at 10:09, Paul E. McKenney wrote:
>
> Please let me know of any questions or concerns.
Ack, all sounds good.
And it wasn't a problem last time either, I just wanted to make it
clear that I don't want to randomly pull from new people without
having some kind of hand-over.
On Mon, 13 May 2024 at 09:56, Paul E. McKenney wrote:
>
> Unless you tell me you want it sooner, we will sending this into the
> v6.11 merge window.
No hurry, just as long as it gets done at some point. Uladzislau is in
my keychain now, so this no longer triggers big warning messages in my
On Mon, 13 May 2024 at 09:46, Paul E. McKenney wrote:
>
> Yes, this is intentional, nothing odd is going on, and Uladzislau's pull
> request is legitimate.
If this is more than a one-time thing, maybe Uladzislau should be in
the MAINTAINERS entry too?
Linus
[ I should have reacted to this earlier, but I just put all the "for
6.10" pull requests in the queue without looking closer ]
On Fri, 10 May 2024 at 11:30, Uladzislau Rezki (Sony) wrote:
>
> Please pull the latest RCU git tree from:
>
> https://github.com/urezki/linux.git tags/rcu.next.v6.10
On Wed, 13 Mar 2024 at 16:29, Florian Fainelli wrote:
>
> On this specific commit 7ee988770326fca440472200c3eb58935fe712f6, there
> is a 100% failure for at least 3 devices out of the 16 that are running
> the test.
Hmm. I have no idea what is going on, and the unimac-mdio probe
function (one
On Tue, 12 Mar 2024 at 14:34, Florian Fainelli wrote:
>
> and here is a log where this fails:
>
> https://gist.github.com/ffainelli/ed08a2b3e853f59343786ebd20364fc8
You could try the 'initcall_debug' kernel command line.
It will make the above *much* noisier, but it might - thanks to all
the
On Thu, 7 Mar 2024 at 13:40, Julia Lawall wrote:
>
> I tried the following:
>
> @@
> expression x;
> @@
>
> *WRITE_ONCE(x,<+...READ_ONCE(x)...+>)
>
> This gave a number of results, shown below. Let me know if some of them
> are undesirable.
Well, all the ones you list do look like garbage.
On Thu, 7 Mar 2024 at 11:47, Paul E. McKenney wrote:
>
> > - The per-thread counter (Thread-Local Storage) incremented by a single
> > thread, read by various threads concurrently, is a good target
> > for WRITE_ONCE()/READ_ONCE() pairing. This is actually what we do in
> > various liburcu
On Wed, 6 Mar 2024 at 18:43, Linus Torvalds
wrote:
>
> I dunno.
Oh, and just looking at that patch, I still think the code is confused.
On the reading side, we have:
pipe_count = smp_load_acquire(>rtort_pipe_count);
if (pipe_count > RCU_TORTURE_PIPE_LEN) {
/* Shoul
On Wed, 6 Mar 2024 at 18:29, Paul E. McKenney wrote:
>
> TL;DR: Those ->rtort_pipe_count increments cannot run concurrently
> with each other or any other update of that field, so that update-side
> READ_ONCE() call is unnecessary and the update-side plain C-language
> read is OK. The
On Wed, 6 Mar 2024 at 11:46, Linus Torvalds
wrote:
>
> That 'rtort_pipe_count' should be an atomic_t, and the "add one and
> return the old value" should be an "atomic_inc_return()-1" (the "-1"
> is because "inc_return" returns the *new* value).
On Wed, 6 Mar 2024 at 11:45, Steven Rostedt wrote:
>
> Here's the back story. I received the following patch:
>
>
> https://lore.kernel.org/all/tencent_ba1473492bc618b473864561ea3ab1418...@qq.com/
>
> I didn't like it. My reply was:
>
> > - rbwork->wait_index++;
> > +
On Wed, 6 Mar 2024 at 11:27, Steven Rostedt wrote:
>
> Note this has nothing to do with tracing. This thread is in RCU. I just
> happen to receive the same patch "fix" for my code.
Ok, googling for rtort_pipe_count, I can only state that that code is
complete garbage.
And no amount of
On Wed, 6 Mar 2024 at 11:01, Linus Torvalds
wrote:
>
> In some individual tracing C file where it has a comment above it how
> it's braindamaged and unsafe and talking about why it's ok in that
> particular context? Go wild.
Actually, I take that back.
Even in a random C file, the
On Wed, 6 Mar 2024 at 10:53, Steven Rostedt wrote:
>
> Now, are you OK with an addition of ADD_ONCE() and/or INC_ONCE()? So that we
> don't have to look at:
>
> WRITE_ONCE(a, READ_ONCE(a) + 1);
>
> ?
In a generic header file under include/linux/?
Absolutely not. The above is a
On Wed, 6 Mar 2024 at 09:59, Steven Rostedt wrote:
>
> IIRC, the original purpose of READ_ONCE() and WRITE_ONCE() was to make sure
> that the compiler only reads or writes the variable "once". Hence the name.
> That way after a load, you don't need to worry that the content of the
> variable you
On Thu, 11 Jan 2024 at 10:33, Neeraj Upadhyay (AMD)
wrote:
>
> Please pull the latest RCU git tree from:
>
> https://github.com/neeraju/linux.git tags/rcu.release.v6.8
Not pulled yet - I have a big pile to go - but an ack that I got the email.
Linus
On Thu, 11 Jan 2024 at 02:52, Paul E. McKenney wrote:
>
> Just following up on Neeraj's RCU pull request from December 23rd:
>
> https://lore.kernel.org/all/20231223021434.GA2714@neeraj.linux/
I do not have that email in my mailbox at all.
I have no idea why - it might have been marked as spam
On Tue, 31 Oct 2023 at 15:08, Paul E. McKenney wrote:
>
> Here are the ways forward I can see:
>
> 1. Status quo. This has all the issues that you call out.
> People will hurt themselves with it and consume time and effort.
> So let's not do this.
Well, at a *minimum*, I
On Tue, 31 Oct 2023 at 03:57, Paul E. McKenney wrote:
>
> Would it help if we make rcu_stall_chain_notifier_register() print a
> suitably obnoxious message saying that future RCU CPU stall warnings
> might be unreliable?
It's not the future stall warnings I worry about.
It's literally things
On Fri, 27 Oct 2023 at 01:33, Frederic Weisbecker wrote:
>
> rcu/stall: Stall detection updates. Introduce RCU CPU Stall notifiers
> that allows a subsystem to provide informations to help debugging.
> Also cure some false positive stalls.
I absolutely detest this stall notifier
21 matches
Mail list logo
