linux-kernel - Re: [PATCH] kernel/signal.c: Export symbol __lock_task

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: <20200622113610.okzntx7jmnk6n7au@wittgenstein>
Date:   Mon, 22 Jun 2020 13:36:10 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     Dominique Martinet <asmadeus@...ewreck.org>
Cc:     Oleg Nesterov <oleg@...hat.com>,
        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 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. 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.

> What about the possibility of sighand being null that the function does
> check, is that impossible for current as well?

See above, I think that's impossible.

> 
> 
> Honestly not a part of the code I'm much familiar with, this all
> predates my involvement with 9p by a fair bit...

We can't be experts in everything. :)

Christian