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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 11 Sep 2014 16:28:22 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Tejun Heo <tj@...nel.org>, 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 Thu 11-09-14 16:32:50, Rafael J. Wysocki wrote:
> On Thursday, September 11, 2014 04:10:51 PM Michal Hocko wrote:
> > On Thu 11-09-14 16:26:56, Rafael J. Wysocki wrote:
> > > On Thursday, September 11, 2014 04:04:48 PM Michal Hocko wrote:
> > > > On Thu 11-09-14 16:17:56, Rafael J. Wysocki wrote:
> > > > [...]
> > > > > And I'm still wondering if the OOM killer may be made avoid killing frozen
> > > > > tasks.
> > > > 
> > > > This is really tricky. OOM killer aims at the biggest memory hog. We
> > > > shouldn't ignore it just because it hides into the fridge... So even
> > > > if we "fix" oom killer to ignore frozen tasks (which is inherently
> > > > racy btw.) then we have a potential problem of freezer abuse (e.g. in
> > > > container environments). So I strongly believe that the OOM killer has
> > > > to be able to kill a frozen tasks.
> > > 
> > > OK
> > > 
> > > Is the OOM killer the only place where TIF_MEMDIE is set?
> > 
> > Yes. To be precise, lowmemorykiller (staging android thingy), global OOM
> > killer and memcg OOM killer. Any other users would be an abuse.
> 
> OK
> 
> So can we ensure that those things don't trigger during system suspend (or
> equivalent) and then simply use the TIF_MEMDIE check in __refrigerator()?

That would require that no memory allocation triggers OOM killer during
suspend. I don't think this will work out. OOM killer is the last resort
action. We cannot simply give access to memory reserves just because the
current context is in the middle of suspend.

What is the worst thing that might happen when a task is killed in the
middle of suspend? I thought that suspend would fail after several
attempts to suspend all existing tasks.

-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ