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] [day] [month] [year] [list]
Message-ID: <20110930153036.GA19095@redhat.com>
Date:	Fri, 30 Sep 2011 17:30:36 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Tejun Heo <htejun@...il.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [patch] oom: thaw threads if oom killed thread is frozen
	before deferring

On 09/29, Michal Hocko wrote:
>
> On Thu 29-09-11 18:37:24, Oleg Nesterov wrote:
> >
> > Oh, I don't think so. For what? This doesn't close other races, and
> > in fact the fatal_signal_pending() this patch adds is itself racy,
> > SIGKILL can come in between.
>
> OK, I think I see your point. You mean that oom will send KILL after
> both fatal_signal_pending in refrigerator and signal_pending check in
> schedule, right?

No, schedule()->signal_pending_state(TASK_UNINTERRUPTIBLE) doesn't check
the signals. I simply meant

	if (fatal_signal_pending())
					// <--- SIGKILL from oom
		try_to_freeze();

> This is what the follow up fix from David is doing. Check frozen in
> select_bad_process if the task is TIF_MEMDIE and thaw the process.
>
> And it seems that the David's follow up fix is sufficient so let's leave
> refrigerator alone.

Agreed, afaics this should fix all races (although I didn't read the
whole discussion, perhaps I missed something else).

And in this case we do not even need to modify oom_kill_task/etc,
select_bad_process() will be called again and notice the frozen task
eventually. Afaics.

Or, as Tejun suggests, we can implement the race-free kill-even-if-frozen
later.

Oleg.

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