linux-kernel - Re: [PATCH 1/6] cpuset write dirty map

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: <Pine.LNX.4.64.0709191006160.10862@schroedinger.engr.sgi.com>
Date:	Wed, 19 Sep 2007 10:08:31 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Ethan Solomita <solo@...gle.com>, linux-mm@...ck.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/6] cpuset write dirty map

On Tue, 18 Sep 2007, Andrew Morton wrote:

> How hard would it be to handle the allocation failure in a more friendly
> manner?  Say, if the allocation failed then point mapping->dirty_nodes at
> some global all-ones nodemask, and then special-case that nodemask in the
> freeing code?

Ack. However, the situation dirty_nodes == NULL && inode dirty then means 
that unknown nodes are dirty. If we are later are successful with the 
alloc and we know that the pages are dirty in the mapping then the initial 
dirty_nodes must be all ones. If this is the first page to be dirtied then 
we can start with a dirty_nodes mask of all zeros like now.

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