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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200622083905.c3nurmkbo5yhd6lj@wittgenstein>
Date:   Mon, 22 Jun 2020 10:39:05 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     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,
        asmadeus@...ewreck.org, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH] kernel/signal.c: Export symbol __lock_task_sighand

On Mon, Jun 22, 2020 at 08:25:28AM +0200, Oleg Nesterov wrote:
> On 06/21, Alexander Kapshuk wrote:
> >
> > Export symbol __lock_task_sighand, so it is accessible from code compiled
> > as modules.
> > This fixes the following modpost error:
> > ERROR: modpost: "__lock_task_sighand" [net/9p/9pnet.ko] undefined!
> >
> > Where __lock_task_sighand is called via lock_task_sighand in net/9p/client.c
> > See https://lore.kernel.org/lkml/20200620201456.14304-1-alexander.kapshuk@gmail.com/.
> 
> Why?
> 
> 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.

[1]: https://lore.kernel.org/lkml/20200620201456.14304-1-alexander.kapshuk@gmail.com/

Christian