From: Oleg Nesterov <oleg@redhat.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Dominique Martinet <asmadeus@codewreck.org>,
Alexander Kapshuk <alexander.kapshuk@gmail.com>,
linux-kernel@vger.kernel.org, ebiederm@xmission.com,
akpm@linux-foundation.org, liuzhiqiang26@huawei.com,
joel@joelfernandes.org, paulmck@linux.vnet.ibm.com,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] kernel/signal.c: Export symbol __lock_task_sighand
Date: Mon, 22 Jun 2020 14:03:00 +0200 [thread overview]
Message-ID: <20200622120259.GD6516@redhat.com> (raw)
In-Reply-To: <20200622113610.okzntx7jmnk6n7au@wittgenstein>
On 06/22, Christian Brauner wrote:
>
> On Mon, Jun 22, 2020 at 12:24:01PM +0200, Dominique Martinet wrote:
> > Christian Brauner wrote on Mon, Jun 22, 2020:
> > > On Mon, Jun 22, 2020 at 08:25:28AM +0200, Oleg Nesterov wrote:
> > >> current->sighand is stable and can't go away. Unless "current" is exiting and
> > >> has already passed exit_notify(). So I don't think net/9p needs this helper.
> > >
> > > From what I can gather from the thread (cf. [1]) that is linked in the
> > > commit message the main motivation for all of this is sparse not being
> > > happy and not some bug. (Maybe I'm not seeing something though.)
> > >
> > > The patch itself linked here doesn't seem to buy anything. I agree with
> > > Oleg. Afaict, lock_task_sighand() would only be needed here if the task
> > > wouldn't be current. So maybe it should just be dropped from the series.
> >
> > Sure. I honestly have no idea on what guarantees we have from the task
> > being current here as opposed to any other task -- I guess that another
> > thread calling exit for exemple would have to wait?
>
> When a thread in a non-trivial thread-group (sorry for the math
> reference :)) execs it'll unshare its struct sighand.
Well, not really...
The execing threads will kill other other threads, then it will check
if ->sighand should be unshared. The latter is very unlikely, I don't
think CLONE_SIGHAND without CLONE_THREAD is actually used today.
But this doesn't really matter. I mean, even if you race with another
thread doing exec/exit/whatever, current->sighand is stable. Unless, again,
current has already exited (called exit_notify()).
> The new struct
> sighand will be assigned using rcu_assign_pointer() so afaik (Paul or
> Oleg can yell at me if I'm talking nonsense) any prior callers will see
> the prior sighand value.
Yes, but see above.
If tsk is not current, then (in general) it is not safe to use tsk->sighand
directly. It can can be changed by exec (as you explained), or you can hit
tsk->sighand == NULL if you race with exit.
Oleg.
next prev parent reply other threads:[~2020-06-22 12:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-21 13:37 [PATCH] kernel/signal.c: Export symbol __lock_task_sighand Alexander Kapshuk
2020-06-21 13:54 ` Dominique Martinet
2020-06-22 8:39 ` Christian Brauner
2020-06-22 8:50 ` Alexander Kapshuk
2020-06-22 6:25 ` Oleg Nesterov
2020-06-22 8:39 ` Christian Brauner
2020-06-22 10:24 ` Dominique Martinet
2020-06-22 11:31 ` Oleg Nesterov
2020-06-22 11:36 ` Christian Brauner
2020-06-22 12:03 ` Oleg Nesterov [this message]
2020-06-22 12:29 ` Christian Brauner
2020-06-22 13:01 ` Oleg Nesterov
2020-06-22 13:04 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200622120259.GD6516@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.kapshuk@gmail.com \
--cc=asmadeus@codewreck.org \
--cc=christian.brauner@ubuntu.com \
--cc=ebiederm@xmission.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuzhiqiang26@huawei.com \
--cc=lkp@intel.com \
--cc=paulmck@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox