[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1IgS3w/M1vnEC8D@gmail.com>
Date: Thu, 20 Oct 2022 21:30:03 -0700
From: Andrei Vagin <avagin@...il.com>
To: Kees Cook <kees@...nel.org>
Cc: linux-kernel@...r.kernel.org,
Andy Lutomirski <luto@...capital.net>,
Christian Brauner <brauner@...nel.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Kees Cook <keescook@...omium.org>,
Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Peter Oskolkov <posk@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Tycho Andersen <tycho@...ho.pizza>,
Will Drewry <wad@...omium.org>,
Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH 1/5] seccomp: don't use semaphore and wait_queue together
On Wed, Oct 19, 2022 at 10:10:44PM -0700, Kees Cook wrote:
> On October 19, 2022 6:10:44 PM PDT, Andrei Vagin <avagin@...il.com> wrote:
> >Here is no reason to use two different primitives that do similar things.
> >
> >Signed-off-by: Andrei Vagin <avagin@...il.com>
> >---
> > kernel/seccomp.c | 41 ++++++++++++++++++++++++++++++++++++-----
> > 1 file changed, 36 insertions(+), 5 deletions(-)
>
> The commit log does not justify adding 29 lines to "do similar
> things". :) Can you describe the rationale and benefits here a bit
> more? I assume this to use the the future new wake_up helper?
The main reason is to use new wake_up helpers, but there are a few
other reasons:
* if we use two different ways, we always need to call them both. This
patch fixes seccomp_notify_recv where we forgot to call wake_up_poll
in the error path.
* If we use one primitive, we can control how many waiters are woken up
for each request. Our goal is to wake up just one that will handle a
request. Right now, wake_up_poll may wake up one waiter and
up(&match->notif->request) may wake up one more.
I will update the commit message. Thanks!
>
>
> --
> Kees Cook
Powered by blists - more mailing lists