[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250813173705.0e910f5a@gandalf.local.home>
Date: Wed, 13 Aug 2025 17:37:05 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Stefan Metzmacher <metze@...ba.org>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>, Dietmar Eggemann
<dietmar.eggemann@....com>, Ben Segall <bsegall@...gle.com>, Mel Gorman
<mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>, Steve French
<smfrench@...il.com>, Namjae Jeon <linkinjeon@...nel.org>,
"linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Questions about wake_up[_interruptible][_all]
On Wed, 13 Aug 2025 22:28:08 +0200
Stefan Metzmacher <metze@...ba.org> wrote:
> I guess I understand the difference between
> wait_event() and wait_event_interruptible(),
> the first ignores any signal even kill and the
> 2nd returns -ERESTARTSYS on any signal.
The main difference is what the code does after the wait_event*().
If you use wait_event_interruptible() the first thing the code should do is
to check if a signal is pending or not. Or at least check some status to
know that what it is waiting for did not happen and handle it properly.
But there's places in the kernel where the task is waiting for something
and it expects that whatever it is waiting for *must* happen eventually and
it should not continue until it does.
Looking at one example: fs/jbd2/journal.c: jbd2_journal_start_thread()
It creates a thread, tests that it is created, and then waits for that
thread to acknowledge that it is running, and the function should not
return until it does.
If someone were to send a signal to that waiter and wake it up prematurely,
the following code may become buggy as it expects the thread to be
initialized and active when it is not.
-- Steve
Powered by blists - more mailing lists