linux-kernel - Re: [PATCH] exit: dump thread info on global init exit

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-next>] [day] [month] [year] [list]

Message-ID: <20231109110129.GB12330@redhat.com>
Date:   Thu, 9 Nov 2023 12:01:30 +0100
From:   Oleg Nesterov <oleg@...hat.com>
To:     lijiazi <qiwuchen55@...il.com>
Cc:     christian.brauner@...ntu.com, axboe@...nel.dk,
        keescook@...omium.org, akpm@...ux-foundation.org,
        mcgrof@...nel.org, ebiederm@...ssion.com, jannh@...gle.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] exit: dump thread info on global init exit

I've just noticed we discuss this offlist. Add lkml...

On 11/09, lijiazi wrote:
>
> On Wed, Nov 08, 2023 at 10:57:32AM +0100, Oleg Nesterov wrote:
>
> > > +	if (mmap_read_lock_killable(mm)) {
> >
> > why do you need _killable ?
> >
> I'm not sure which type lock (killable or unkillable) should be used here

killable should be used to allow to kill the task which waits for this lock.
Who can kill the global init? Yes it is possible (but very unlikely) that
fatal_signal_pending() is true, but I don't think this was your concern.

> if there is a lock contention, perhaps using down_read_trylock is better.

Perhaps. If we have another bug mmap_read_lock() can hang forever.

> > > +static void dump_thread_info(struct task_struct *tsk)
> > > +{
> > > +	struct pt_regs *regs = task_pt_regs(tsk);
> > > +
> > > +	if (user_mode(regs))
> > > +		dump_thread_maps_info(tsk);
> > > +	show_regs(regs);
> >
> > This looks confusing to me...
> >
> > How can user_mode() return false in this case? And even if this is
> > possible, then show_regs() should depend on user_mode() as well?
> > I must have missed something.
> >
> Sure, the last global init thread cannot be exited in non-user mode.

Forgot to mention... panic() should dump the regs, so I think show_regs()
is not needed?

Oleg.