linux-kernel - Re: [PATCH 3/4] mm: vrealloc: properly document __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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZqlsdtTWhRahFWmy@pollux.localdomain>
Date: Wed, 31 Jul 2024 00:43:02 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: urezki@...il.com, hch@...radead.org, vbabka@...e.cz, mhocko@...e.com,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 3/4] mm: vrealloc: properly document __GFP_ZERO behavior

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@...nel.org> 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@kernel.org/
[2] https://lore.kernel.org/linux-mm/20240722163111.4766-1-dakr@kernel.org/T/#m065a7f875b44dc945dd535c2b7168c3d77a98993