linux-kernel - Re: Questions about wake_up[_interruptible][

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250814224717.192b625d@batman.local.home>
Date: Thu, 14 Aug 2025 22:47:17 -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 Thu, 14 Aug 2025 09:57:14 +0200
Stefan Metzmacher <metze@...ba.org> wrote:

> Am 13.08.25 um 23:37 schrieb Steven Rostedt:
> > 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.  
> 
> Thanks!
> 
> Via a private channel I also got this answer:
> 
> wake_up_interruptible() only wakes tasks that are in the
> TASK_INTERRUPTIBLE state.
> 
> wake_up() wakes tasks that are in either the TASK_INTERRUPTIBLE or
> TASK_UNINTERRUPTIBLE state, as per the TASK_NORMAL macro used in the
> definition of wake_up().
> 
> Call chain:
> 
> wake_up_interruptible
>    __wake_up(mode = TASK_INTERRUPTIBLE)
>      __wake_up_common_lock(mode = TASK_INTERRUPTIBLE)
>        __wake_up_common(mode = TASK_INTERRUPTIBLE)
>          curr->func(mode = TASK_INTERRUPTIBLE)
>            // curr->func is usually default_wake_function
>            default_wake_function(mode = TASK_INTERRUPTIBLE)
>              try_to_wake_up(state = TASK_INTERRUPTIBLE)
>                ttwu_state_match(state = TASK_INTERRUPTIBLE)
>                  __task_state_match(state = TASK_INTERRUPTIBLE):
>                  if (READ_ONCE(p->__state) & state) ...
> 

That's a differentiation in implementation, but I thought your question
was more about what the differentiation in the purpose of the two.

-- Steve