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: <20140915142821.GF19976@dhcp22.suse.cz>
Date:	Mon, 15 Sep 2014 16:28:21 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Tejun Heo <tj@...nel.org>
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

On Sat 13-09-14 08:48:46, Tejun Heo wrote:
> Hello, Michal.
> 
> On Wed, Sep 10, 2014 at 03:24:17PM +0200, Michal Hocko wrote:
> > What do you think about this way to help distinguish kernel threads and
> > user processes and keep the future maintenance of freezer saner?
> 
> I'm not sure either way.  Please note that we have quite a few
> wrappers around try_to_freeze() - freezable_schedule*() and
> wait_event_freezable*() - and several places where a userland can be
> frozen.  

I wasn't aware of those until I discovered freezer_count and company. I
didn't get to study why we need so many freezing point in the kernel yet
and whether they are safe at all. 

> Are we gonna introduce an alternate versions for all of them?

Are they intended for kernel threads in the first place? The primary
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
threads know they might freeze themselves when returning from schedule,
no?

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.

> 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
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.
-- 
Michal Hocko
SUSE Labs
--
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/