[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjUZLybZBJgOtD2gng=FS7USrbQQ1-tn5M+UP5DbCWdzw@mail.gmail.com>
Date: Wed, 29 Apr 2020 16:22:08 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Bernd Edlinger <bernd.edlinger@...mail.de>
Cc: Jann Horn <jannh@...gle.com>, Oleg Nesterov <oleg@...hat.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Waiman Long <longman@...hat.com>,
Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alexey Gladkov <gladkov.alexey@...il.com>
Subject: Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1
On Wed, Apr 29, 2020 at 3:38 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> If you do it properly, with a helper function instead of repeating
> that fragile nasty thing, maybe it will look better to me.
Side note: if it has a special helper function for the "get lock,
repeat if it was invalid", you can do a better job than return
-EAGAIN.
In particular, you can do this
set_thread_flag(TIF_SIGPENDING);
return -RESTARTNOINTR;
which will actually restart the system call. So a ptrace() user (or
somebody doing a "write()" to /proc/<pid>/attr/xyz, wouldn't even see
the impossible EAGAIN error.
But that all requires that you have some locking helper routines like
int lock_exec_creds(struct task_struct *);
void unlock_exec_guard(struct task_struct *);
because there's no way we put that kind of super-fragile code in
several places. It would be very much one single routine with a *HUGE*
comment on it.
Linus
Powered by blists - more mailing lists