Message-ID: <20200622122925.khcilncycuzb4xki@wittgenstein>
Date:   Mon, 22 Jun 2020 14:29:25 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     Dominique Martinet <asmadeus@...ewreck.org>,
        Alexander Kapshuk <alexander.kapshuk@...il.com>,
        linux-kernel@...r.kernel.org, ebiederm@...ssion.com,
        akpm@...ux-foundation.org, liuzhiqiang26@...wei.com,
        joel@...lfernandes.org, paulmck@...ux.vnet.ibm.com,
        kernel test robot <lkp@...el.com>
Subject: Re: [PATCH] kernel/signal.c: Export symbol __lock_task_sighand

On Mon, Jun 22, 2020 at 02:03:00PM +0200, Oleg Nesterov wrote:
> 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

I know but I didn't want to go into that much detail but you're right of
course! :)

> if ->sighand should be unshared. The latter is very unlikely, I don't
> think CLONE_SIGHAND without CLONE_THREAD is actually used today.

It is a supported case however unlikely. I just tried to answer
Dominique's specific question pointing out that even in that unlikely
case sighand_struct is stable.

Just as an fyi, CLONE_SIGHAND with CLONE_VM but without CLONE_THREAD is
actually used quite a bit, e.g. in newlib, in stress-ng, and in criu.
Actually for some use-cases with userfaultfd if you want to handle
pagefaults in the child, you'd want CLONE_VM which enforces
CLONE_SIGHAND so that would be another use-case afaict.

And honestly, quite often this combo is used in helper processes that
share as much context as possible without CLONE_THREAD to do as little
work as possible in terms of allocations and so on in the kernel.
(Another interesting use-case could arise with CLONE_SIGHAND +
 CLONE_CLEAR_SIGHAND as it allows you to reset both the parent's and
 child's signal handler in one shot.)

> 
> 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.
> 

Powered by blists - more mailing lists