linux-kernel - Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)

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: <20181203171801.GF31738@dhcp22.suse.cz>
Date:   Mon, 3 Dec 2018 18:18:01 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     pavel@....cz, Oleg Nesterov <oleg@...hat.com>,
        Ingo Molnar <mingo@...nel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        rafael.j.wysocki@...el.com, chanho.min@....com,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux
 4.20-rc4)

On Mon 03-12-18 09:06:18, Linus Torvalds wrote:
> On Mon, Dec 3, 2018 at 6:17 AM Michal Hocko <mhocko@...nel.org> wrote:
> >
> > This argument just doesn't make any sense. Rare bugs are maybe even more
> > annoying because you do not expect them to happen.
> 
> Absolutely.
> 
> And valid lockdep complaints are a real issue too.

No questions about that. But in this case there is no real deadlock so
the splat is disputable. And we have a "do not use" freezable_schedule_unsafe
which shouldn't tigger the splat yet it would make the suspend issue go
away AFIU. Not a great fix and we should target for something better
long term but good enough as a poor's man stop gap fix.

> So I don't think there's any question that this should be reverted,
> the only question is whether I take the revert directly or get it from
> the PM tree.
> 
> It does sound like the de_thread() behavior needs more work. Maybe,
> for example, we need to make it clear that zapped threads are *not*
> frozen, and instead the freezer will wait for them to exit?

I was actually proposing something like that during the review
discussion. Basically set PF_NOFREEZE all the threads and wake them up.
But that is not so simple because they might be at any path when they
sleep (this is the biggest design flaw of the freezer IMHO).

-- 
Michal Hocko
SUSE Labs