Re: [PATCH 3/4] mm: vrealloc: properly document __GFP_ZERO behavior
From: Danilo Krummrich
Date: Tue Jul 30 2024 - 18:43:15 EST
On Tue, Jul 30, 2024 at 02:19:53PM -0700, Andrew Morton wrote:
> On Tue, 30 Jul 2024 20:49:43 +0200 Danilo Krummrich <dakr@xxxxxxxxxx> wrote:
>
> > Properly document that if __GFP_ZERO logic is requested, callers must
> > ensure that, starting with the initial memory allocation, every
> > subsequent call to this API for the same memory allocation is flagged
> > with __GFP_ZERO. Otherwise, it is possible that __GFP_ZERO is not fully
> > honored by this API.
>
> I appear to have just seen this, in a separate mailing.
What you have seen in a separate mail is a similar patch for krealloc() [1].
This one is a fixup for vrealloc() from a previous submission you've applied to
mm-unstable.
>
> Please, slow down. We have two months. Await reviewer feedback, spend
> time over those changelogs, value clarity and accuracy and completeness
> over hastiness. The only reason for rushing things is if a patch is
> disrupting ongoing testing of the linux-next tree.
There was a discussion in [2], which lead to this fixup series.
In terms of changelogs this series is indeed a bit "lax", since I have
recognized that you queue up fixup patches for changes that did already land in
mm-unstable to be squashed into the original commits later on.
[1] https://lore.kernel.org/linux-mm/20240730194214.31483-1-dakr@xxxxxxxxxx/
[2] https://lore.kernel.org/linux-mm/20240722163111.4766-1-dakr@xxxxxxxxxx/T/#m065a7f875b44dc945dd535c2b7168c3d77a98993