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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ