linux-kernel - Re: [patch] cpusets: do not allow TIF

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: <Pine.LNX.4.64.0706051653330.6473@schroedinger.engr.sgi.com>
Date:	Tue, 5 Jun 2007 16:57:30 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	David Rientjes <rientjes@...gle.com>
cc:	Paul Jackson <pj@....com>, akpm@...ux-foundation.org, ak@...e.de,
	clameter@...ulhu.engr.sgi.com, linux-kernel@...r.kernel.org
Subject: Re: [patch] cpusets: do not allow TIF_MEMDIE tasks to allocate
 globally

On Tue, 5 Jun 2007, David Rientjes wrote:

> If that fails, we can't allocate elsewhere because then we have taken 
> exclusive memory from other applications and is contrary to the definition 
> of mem_exclusive.  You need to construct your cpuset hierarchy with these 
> scenarios in mind; when you ask for an exclusive cpuset, it shouldn't come 
> with a disclaimer that says "if another cpuset that is also exclusive 
> happens to OOM, we'll steal your memory anyway and it's not our problem if 
> the dying task gets stuck in D state and doesn't exit synchronously or 
> reliably because all we did was send it a SIGKILL."

Exclusive is not as absolute as you may think. There is also the 
GFP_KERNEL exception.

Processes stuck in D state is another issue with reliability.

> > So its seems that the patch is addressing an imagined situation?
> No, it's returning us to the previous logic where an exclusive cpuset was 
> actually exclusive.
> 
> And, again, without this change it is possible to allocate in other 
> exclusive cpusets without first exhausting your own memory reserves.  
> That's wrong.

That is already occurring with GFP_KERNEL. So your patch really does not 
have the purifying effect on exclusivity that you expect. This looks all 
more like hunting for elusive idealistic cpuset behavior to me.

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