linux-kernel - Re: [PATCH 06/10] mm, page_alloc: Rename __GFP_WAIT to __GFP

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: <560CF134.2060107@suse.cz>
Date:	Thu, 1 Oct 2015 10:39:16 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Mel Gorman <mgorman@...hsingularity.net>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Johannes Weiner <hannes@...xchg.org>,
	Rik van Riel <riel@...hat.com>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Michal Hocko <mhocko@...nel.org>,
	Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 06/10] mm, page_alloc: Rename __GFP_WAIT to __GFP_RECLAIM

On 09/29/2015 03:37 PM, Mel Gorman wrote:
> mm: page_alloc: Hide some GFP internals and document the bits and flag combinations
>
> Andrew started the following
>
> 	We have quite a history of remote parts of the kernel using
> 	weird/wrong/inexplicable combinations of __GFP_ flags.	I tend
> 	to think that this is because we didn't adequately explain the
> 	interface.
>
> 	And I don't think that gfp.h really improved much in this area as
> 	a result of this patchset.  Could you go through it some time and
> 	decide if we've adequately documented all this stuff?
>
> This patches first moves some GFP flag combinations that are part of the MM
> internals to mm/internal.h. The rest of the patch documents the __GFP_FOO
> bits under various headings and then documents the flag combinations. It
> will not help callers that are brain damaged but the clarity might motivate
> some fixes and avoid future mistakes.
>
> Signed-off-by: Mel Gorman <mgorman@...hsingularity.net>

Acked-by: Vlastimil Babka <vbabka@...e.cz>

With some nitpicks below.

> +/*
> + * Reclaim modifiers
> + *
> + * __GFP_IO can start physical IO.
> + *
> + * __GFP_FS can call down to the low-level FS. Avoids the allocator

"Clearing the flag avoids..."? Avoids confusion.

> + *   recursing into the filesystem which might already be holding locks.
> + *
> + * __GFP_DIRECT_RECLAIM indicates that the caller may enter direct reclaim.
> + *   This flag can be cleared to avoid unnecessary delays when a fallback
> + *   option is available.
> + *
> + * __GFP_KSWAPD_RECLAIM indicates that the caller wants kswapd when the low

s/wants/wakes/? or "wants kswapd woken up"?

> + * GFP_USER is for userspace allocations that also need to be directly
> + *   accessibly by the kernel or hardware. It is typically used by hardware
> + *   for buffers that are mapped to userspace (e.g. graphics) that hardware
> + *   still must DMA to. cpuset limits are enforced for these allocations.
> + *
> + * GFP_HIGHUSER is for userspace allocations that may be mapped to userspace,
> + *   do not need to be directly accessible by the kernel but that cannot
> + *   move once in use. An example may be a hardware allocation that maps
> + *   data directly into userspace but has no addressing limitations.
> + *
> + * GFP_DMA exists for historical reasons and should be avoided where possible.
> + *   The flags indicates that the caller requires that the lowest zone be
> + *   used (ZONE_DMA or 16M on x86-64). Ideally, this would be removed but
> + *   it would require careful auditing as some users really require it and
> + *   others use the flag to avoid lowmem reserves in ZONE_DMA and treat the
> + *   lowest zone as a type of emergency reserve.
> + *
> + * GFP_DMA32 is similar to GFP_DMA except that the caller requires a 32-bit
> + *   address.
> + *
> + * GFP_HIGHUSER_MOVABLE is for userspace allocations that the kernel does not
> + *   need direct access to but can use kmap() when access is required. They
> + *   are expected to be movable via page reclaim or page migration. Typically,
> + *   pages on the LRU would also be allocated with GFP_HIGHUSER_MOVABLE.

Move GFP_HIGHUSER_MOVABLE right below GFP_HIGHUSER?

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