linux-kernel - Re: [GIT PULL] signal/exit/ptrace changes for v5.17

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wheeokE5rr_64iS_qnKmzSH4=e2Ds2L3gR_zSH=Cr4F5w@mail.gmail.com>
Date:   Mon, 17 Jan 2022 06:15:16 +0200
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Alexey Gladkov <legion@...nel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Kees Cook <keescook@...omium.org>,
        Oleg Nesterov <oleg@...hat.com>
Subject: Re: [GIT PULL] signal/exit/ptrace changes for v5.17

On Mon, Jan 17, 2022 at 6:08 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
>
> People sometimes think that is just a "poll/select()" thing, but
> that's not at all true. It's quite valid to do things like
>
>         add_wait_queue(..)
>         for (.. some loop ..) {
>                 set_current_state(TASK_INTERRUPTIBLE);
>                 ... do various things, checking state etc ..
>                schedule();
>         }
>         set_current_state(TASK_RUNNABLE);
>         remove_wait_queue();

Of course, in most modern cases, the above sequence is actually
encoded as a "wait_event_interruptible()", because we don't generally
want to open-code the whole thing.

But the actual end result still ends up being exactly the same, it's
just syntactically denser and more legible version of the above thing,
and you can still have the "event" you wait on have nested waiting
situations.

The nested waiting is by no means common. The only _common_situation
where you're on multiple wait queues tends to be select/poll kind of
things, when they aren't really nested as much as iterated over, but
conceptually the nested case is still quite important, and it allows
you to do things that a traditional "wait_on()" interface with just
one single wait-queue just doesn't allow for.

                Linus