linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	joel@joelfernandes.org, linke li <lilinke99@qq.com>,
	Rabin Vincent <rabin@rab.in>
Subject: Re: [PATCH 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters
Date: Fri, 8 Mar 2024 16:35:28 -0500	[thread overview]
Message-ID: <20240308163528.3980c639@gandalf.local.home> (raw)
In-Reply-To: <CAHk-=wgsNgewHFxZAJiAQznwPMqEtQmi1waeS2O1v6L4c_Um5A@mail.gmail.com>

On Fri, 8 Mar 2024 12:39:10 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, 8 Mar 2024 at 10:38, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > A patch was sent to "fix" the wait_index variable that is used to help with
> > waking of waiters on the ring buffer. The patch was rejected, but I started
> > looking at associated code. Discussing it on IRC with Mathieu Desnoyers
> > we discovered a design flaw.  
> 
> Honestly, all of this seems excessively complicated.
> 
> And your new locking shouldn't be necessary if you just do things much
> more simply.

You mean to replace the wait_woken_*() code (that has the new locking)?

> 
> Here's what I *think* you should do:
> 
>   struct xyz {
>         ...
>         atomic_t seq;
>         struct wait_queue_head seq_wait;
>         ...
>   };
> 
> with the consumer doing something very simple like this:
> 
>         int seq = atomic_read_acquire(&my->seq);
>         for (;;) {
>                 .. consume outstanding events ..
>                 seq = wait_for_seq_change(seq, my);
>         }
> 
> and the producer being similarly trivial, just having a
> "add_seq_event()" at the end:
> 
>         ... add whatever event ..
>         add_seq_event(my);
> 
> And the helper functions for this are really darn simple:
> 
>   static inline int wait_for_seq_change(int old, struct xyz *my)
>   {
>         int new;
>         wait_event(my->seq_wait,
>                 (new = atomic_read_acquire(&my->seq)) != old);

But the index isn't the only condition for it to wake up to. If the file is
closing, it want's to know that too. Or if it's just being kicked out to
consume whatever is there and ignore the watermark.

>         return new;
>   }
> 
>   static inline void add_seq_event(struct xyz *my)
>   {
>         atomic_fetch_inc_release(&my->seq);
>         wake_up(&my->seq_wait);
>   }

But it's not only the producer that does the wakeup. That part wasn't
broken.

The broken part is a third party that comes along and wants to wake up the
consumer and tell them to just consume what's there and exit.

There's two layers:

1) the ring buffer has the above simple producer / consumer.
   Where the wake ups can happen at the point of where the buffer has
   the amount filled that the consumer wants to start consuming with.

2) The tracing layer; Here on close of a file, the consumers need to be
   woken up and not wait again. And just take whatever was there to finish
   reading.

   There's also another case that the ioctl() just kicks the current
   readers out, but doesn't care about new readers.

I'm not sure how the seq can handle both there being enough data to wake up
the consumer and the case that another task just wants the consume to wake
up and ignore the watermark.

The wake_woken_*() code was only for the second part (to wake up consumers
and tell them to no longer wait for the producer), and had nothing to do
with the produce/consumer part.

-- Steve

  reply	other threads:[~2024-03-08 21:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-08 18:38 [PATCH 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters Steven Rostedt
2024-03-08 18:38 ` [PATCH 1/6] ring-buffer: Fix waking up ring buffer readers Steven Rostedt
2024-03-08 18:38 ` [PATCH 2/6] ring-buffer: Fix resetting of shortest_full Steven Rostedt
2024-03-08 18:38 ` [PATCH 3/6] tracing: Use .flush() call to wake up readers Steven Rostedt
2024-03-08 18:38 ` [PATCH 4/6] tracing: Fix waking up tracing readers Steven Rostedt
2024-03-08 19:13   ` Steven Rostedt
2024-03-08 18:38 ` [PATCH 5/6] ring-buffer: Restructure ring_buffer_wait() to prepare for updates Steven Rostedt
2024-03-08 18:38 ` [PATCH 6/6] tracing/ring-buffer: Fix wait_on_pipe() race Steven Rostedt
2024-03-08 20:39 ` [PATCH 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters Linus Torvalds
2024-03-08 21:35   ` Steven Rostedt [this message]
2024-03-08 21:39     ` Linus Torvalds
2024-03-08 21:41       ` Linus Torvalds
2024-03-10 16:19         ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240308163528.3980c639@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=joel@joelfernandes.org \
    --cc=lilinke99@qq.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=rabin@rab.in \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).