linux-kernel - Re: [Patch v4 1/2] freezer: check OOM kill while being frozen

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: <20140916055610.GB805@mtj.dyndns.org>
Date:	Tue, 16 Sep 2014 14:56:10 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Cong Wang <xiyou.wangcong@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [Patch v4 1/2] freezer: check OOM kill while being frozen

Hello, Michal.

On Mon, Sep 15, 2014 at 04:28:21PM +0200, Michal Hocko wrote:
> > Are we gonna introduce an alternate versions for all of them?
> 
> Are they intended for kernel threads in the first place? The primary

There's no restriction in using them and I'm pretty sure some of them
are used by kernel threads.

> objective seems to be to not wake up user tasks just to put them into
> the fridge when you know they are in a "deep" sleep currently. Kernel

That's one of the uses but not the only one.

> threads know they might freeze themselves when returning from schedule,
> no?

I'm not following.  Can you elaborate?

> freezable_schedule{_timeout} seem to be used only by user tasks AFAICS.
> freezable_schedule_unsafe seems to be more complicated due to nfs and
> cifs but both of them are checking for fatal signal pending and return
> ERESTARTSYS which looks like userspace stuff. So maybe we do not need
> any alternate version for kernel threads.
> 
> I haven't check the workqueue_freezable API.

That one is actually easy and should be fine.

> > What do we actually gain?
> 
> I thought we could easily document and add some rules to where
> try_to_freeze can be called from for userspace tasks. Kernel threads
> know when they are safe to get frozen but we should be more careful
> about user tasks. Whether that can be enforced by an API is a question.
> I do admit this much more complicated than I originally anticipated.
> 
> try_to_freeze should be a nice barrier where you know that waking into
> a new world is safe for the caller (there is no state crossing the

It isn't and I'm not sure it can ever be used as "world" barrier.  It
just doesn't mean that.

> freezing point). Whether a separate API makes this happen is an open
> question. I would hope for much higher bar for adding new freezing
> points for users tasks as those are more tricky to check.

Heh, as far as I can recall, freezer usage has always been a rather
large mess.  In the long term, I think the right thing to do is
merging userland freezing into job control stop so that it doesn't get
the special SIGKILL immunity.  We shouldn't have exposed this
unkillable state the beginning.  :(

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/