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]

Date:	Tue, 9 Sep 2014 19:12:13 +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 Wed 10-09-14 01:46:58, Tejun Heo wrote:
> Hello,
> 
> On Tue, Sep 09, 2014 at 06:06:25PM +0200, Michal Hocko wrote:
> > > Even for userland tasks, try_to_freeze() can currently be anywhere in
> > > the kernel.  The frequently used ones are few but there are some odd
> > 
> > I always thought that user space tasks can be in the fridge only on the
> > way out from the kernel (get_signal_to_deliver). I have quickly greped
> 
> It *can* be anywhere.  We used to have some deep in nfs.  They got
> removed later due to deadlocks but in theory they still can be
> anywhere.
> 
> > the code and the only place I can see seems to be run_guest but that
> > one bails out quickly when there are signals pending so it should be
> > safe in this context.
> > cifs is doing something suspicious (cifs_reconnect) but I didn't check
> > more closely all the contexts it is called from.
> 
> Prolly something similar with what nfs was doing?
> 
> > > ones out, and, again, there's nothing enforcing any structure on
> > > try_to_freeze() usage. 
> > 
> > Would it make sense to have try_to_freeze_user_task or similar and check
> > for kernel thread in try_to_freeze and complain loudly if called from
> > user task context? I mean does it even make sense to call try_to_freeze
> > in the middle of kernel operation for a user task?
> 
> I personally think the whole try_to_freeze() was a mistake at least
> for userland tasks.  We should have collected them in a (mostly)
> single place like a jobctl stop.  I'm not sure whether distinguishing
> the two interfaces would buy us much tho.

We can at least catch those who are doing something dubious. Then we
would have only a single place for user tasks and signal handling code
makes sense to me.

> > > The other thing is that we may do quite a bit during exiting including
> > > allocating memory. 
> > 
> > yes, we can allocate memory and even page fault on the exit path. But
> > TIF_MEMDIE will make sure that the allocation will be successful if
> > there is some memory left.
> 
> TIF_MEMDIE ensures forward progress so that the task can exit;
> however, I'm not sure whether all the things that a task does during
> exit are safe for PM freezes.

Last time we were discussing this it was safe (I cannot
find the particular discussion but here is the Rafael's
Ack for the previous patch which handled the same case
http://lkml.iu.edu//hypermail/linux/kernel/1109.3/00448.html)
-- 
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/