linux-kernel - Re: Pagecache: find_or_create_page does not call a proper page allocator function

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.0704241354470.13382@schroedinger.engr.sgi.com>
Date:	Tue, 24 Apr 2007 13:58:35 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Hugh Dickins <hugh@...itas.com>, Nick Piggin <npiggin@...e.de>,
	linux-kernel@...r.kernel.org, pj@....com
Subject: Re: Pagecache: find_or_create_page does not call a proper page
 allocator function

On Tue, 24 Apr 2007, Andrew Morton wrote:

> > Then I think we should disable page migration for allocations that do not 
> > allow access to the policy zone. That would fix it.
> 
> Can't we use mapping_gfp_mask() when allocating the destination page?

There is no point in migrating something if you cannot reach the 
destination. If the policy zone is not allowed by an allocation then the 
page cannot be migrated because (on 32 bit NUMA) there is only a single 
ZONE_NORMAL on the system. A different node requires a HIGHMEM allocation!

> It would be better to do so, really.  Who knows, mapping_gfp_mask() might
> be extented in the future to say "I want GFP_NOIO" or something.  Or a
> filesystem might specify GFP_KERNEL for regular pagecache pages or
> whatever.

Hmmm..... How about a VM_DONTMIGRATE flag instead? That would be easy to 
check and could be set by a device that must have all pages of the address
space conforming to the gfp mask.

Or more general

VM_STRICT_ALLOC?

> Generally, the interface is "address_space tells core kernel how to
> allocate its pages", and to be nice we should honour that in all places
> where we allocate a page for an address_space.
> 
> If we'd had any brains we would have implemented this function as an
> address_space_operations callback, but we don't so we didn't.

We have enough flags I think.
-
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/