From: Jonathan Corbet <corbet@lwn.net>
To: Dave Martin <Dave.Martin@arm.com>, linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org, Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH] docs/core-api: memory-allocation: GFP_NOWAIT doesn't need __GFP_NOWARN
Date: Mon, 29 Jul 2024 15:11:01 -0600 [thread overview]
Message-ID: <877cd3aopm.fsf@trenco.lwn.net> (raw)
In-Reply-To: <20240729140127.244606-1-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> Since v6.8 the definition of GFP_NOWAIT has implied __GFP_NOWARN,
> so it is now redundant to add this flag explicitly.
>
> Update the docs to match, and emphasise the need for a fallback
> when using GFP_NOWAIT.
>
> Fixes: 16f5dfbc851b ("gfp: include __GFP_NOWARN in GFP_NOWAIT")
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
>
> ---
>
> Based on: v6.11-rc1
>
> This change also evaporates the apparent typo of __GFP_NOWARN without
> the underscores in the documentation, but that doesn't really feel like
> it merits a dedicated patch.
>
> Not sure if this really merits a Fixes tag, but the docmuentation
> update might as well be picked into trees that have the corresponding
> code change.
>
> ---
> Documentation/core-api/memory-allocation.rst | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst
> index 8b84eb4bdae7..0f19dd524323 100644
> --- a/Documentation/core-api/memory-allocation.rst
> +++ b/Documentation/core-api/memory-allocation.rst
> @@ -45,8 +45,9 @@ here we briefly outline their recommended usage:
> * If the allocation is performed from an atomic context, e.g interrupt
> handler, use ``GFP_NOWAIT``. This flag prevents direct reclaim and
> IO or filesystem operations. Consequently, under memory pressure
> - ``GFP_NOWAIT`` allocation is likely to fail. Allocations which
> - have a reasonable fallback should be using ``GFP_NOWARN``.
> + ``GFP_NOWAIT`` allocation is likely to fail. Users of this flag need
> + to provide a suitable fallback to cope with such failures where
> + appropriate.
> * If you think that accessing memory reserves is justified and the kernel
Applied, thanks.
jon
prev parent reply other threads:[~2024-07-29 21:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 14:01 [PATCH] docs/core-api: memory-allocation: GFP_NOWAIT doesn't need __GFP_NOWARN Dave Martin
2024-07-29 14:22 ` Matthew Wilcox
2024-07-29 15:49 ` Mike Rapoport
2024-07-29 21:11 ` Jonathan Corbet [this message]
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=877cd3aopm.fsf@trenco.lwn.net \
--to=corbet@lwn.net \
--cc=Dave.Martin@arm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rppt@kernel.org \
--cc=willy@infradead.org \
/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.