All of lore.kernel.org
 help / color / mirror / Atom feed
From: "NeilBrown" <neilb@suse.de>
To: "Michal Hocko" <mhocko@kernel.org>
Cc: linux-mm@kvack.org, "Dave Chinner" <david@fromorbit.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Christoph Hellwig" <hch@infradead.org>,
	"Uladzislau Rezki" <urezki@gmail.com>,
	linux-fsdevel@vger.kernel.org,
	"LKML" <linux-kernel@vger.kernel.org>,
	"Ilya Dryomov" <idryomov@gmail.com>,
	"Jeff Layton" <jlayton@kernel.org>,
	"Michal Hocko" <mhocko@suse.com>
Subject: Re: [PATCH 3/4] mm/vmalloc: be more explicit about supported gfp flags.
Date: Tue, 26 Oct 2021 10:26:06 +1100	[thread overview]
Message-ID: <163520436674.16092.18372437960890952300@noble.neil.brown.name> (raw)
In-Reply-To: <20211025150223.13621-4-mhocko@kernel.org>

On Tue, 26 Oct 2021, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> The core of the vmalloc allocator __vmalloc_area_node doesn't say
> anything about gfp mask argument. Not all gfp flags are supported
> though. Be more explicit about constrains.
> 
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
>  mm/vmalloc.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 602649919a9d..2199d821c981 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2980,8 +2980,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
>   * @caller:		  caller's return address
>   *
>   * Allocate enough pages to cover @size from the page level
> - * allocator with @gfp_mask flags.  Map them into contiguous
> - * kernel virtual space, using a pagetable protection of @prot.
> + * allocator with @gfp_mask flags. Please note that the full set of gfp
> + * flags are not supported. GFP_KERNEL would be a preferred allocation mode
> + * but GFP_NOFS and GFP_NOIO are supported as well. Zone modifiers are not

In what sense is GFP_KERNEL "preferred"??
The choice of GFP_NOFS, when necessary, isn't based on preference but
on need.

I understand that you would prefer no one ever used GFP_NOFs ever - just
use the scope API.  I even agree.  But this is not the place to make
that case. 

> + * supported. From the reclaim modifiers__GFP_DIRECT_RECLAIM is required (aka
> + * GFP_NOWAIT is not supported) and only __GFP_NOFAIL is supported (aka

I don't think "aka" is the right thing to use here.  It is short for
"also known as" and there is nothing that is being known as something
else.
It would be appropriate to say (i.e. GFP_NOWAIT is not supported).
"i.e." is short for the Latin "id est" which means "that is" and
normally introduces an alternate description (whereas aka introduces an
alternate name).


> + * __GFP_NORETRY and __GFP_RETRY_MAYFAIL are not supported).

Why do you think __GFP_NORETRY and __GFP_RETRY_MAYFAIL are not supported.

> + * __GFP_NOWARN can be used to suppress error messages about failures.

Surely "NOWARN" suppresses warning messages, not error messages ....

Thanks,
NeilBrown


> + * 
> + * Map them into contiguous kernel virtual space, using a pagetable
> + * protection of @prot.
>   *
>   * Return: the address of the area or %NULL on failure
>   */
> -- 
> 2.30.2
> 
> 

  reply	other threads:[~2021-10-25 23:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-25 15:02 [PATCH 0/4] extend vmalloc support for constrained allocations Michal Hocko
2021-10-25 15:02 ` [PATCH 1/4] mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc Michal Hocko
2021-10-25 15:02 ` [PATCH 2/4] mm/vmalloc: add support for __GFP_NOFAIL Michal Hocko
2021-10-25 22:59   ` NeilBrown
2021-10-26  7:03     ` Michal Hocko
2021-10-26 10:30       ` NeilBrown
2021-10-26 11:29         ` Michal Hocko
2021-10-26 15:48   ` Uladzislau Rezki
2021-10-26 16:28     ` Michal Hocko
2021-10-26 19:33       ` Uladzislau Rezki
2021-10-27  6:46         ` Michal Hocko
2021-10-27 17:55         ` Uladzislau Rezki
2021-10-29  7:57           ` Michal Hocko
2021-10-29 14:05             ` Uladzislau Rezki
2021-10-29 14:45               ` Michal Hocko
2021-10-29 17:23                 ` Uladzislau Rezki
2021-10-25 15:02 ` [PATCH 3/4] mm/vmalloc: be more explicit about supported gfp flags Michal Hocko
2021-10-25 23:26   ` NeilBrown [this message]
2021-10-26  7:10     ` Michal Hocko
2021-10-26 10:43       ` NeilBrown
2021-10-26 12:20         ` Michal Hocko
2021-10-25 15:02 ` [PATCH 4/4] mm: allow !GFP_KERNEL allocations for kvmalloc Michal Hocko
2021-10-25 23:34   ` NeilBrown
2021-10-26  7:15     ` Michal Hocko
2021-10-26 10:48       ` NeilBrown
2021-10-26 12:23         ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=163520436674.16092.18372437960890952300@noble.neil.brown.name \
    --to=neilb@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=urezki@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.