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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ZqpT8n3SduevSg7z@pollux>
Date: Wed, 31 Jul 2024 17:10:42 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Andrew Morton <akpm@...ux-foundation.org>, urezki@...il.com,
	hch@...radead.org, 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 Wed, Jul 31, 2024 at 04:43:39PM +0200, Vlastimil Babka wrote:
> On 7/31/24 12:43 AM, Danilo Krummrich wrote:
> > 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.
> 
> Some of the changes in the fixups would however ideally result in udpdates
> to the original changelogs in addition to squashing code. Also with 4 fixups
> to 2 original patches it might be IMHO better to squash on your side and
> resend as a full replacement. Perhaps also together with the other 2 patches
> about __GFP_ZERO for krealloc in a single series. As Andrew mentioned we are
> early in the rc phase to afford this.

(JFYI, Andrew applied the fixups meanwhile.)

I also don't think that they lead to updates of the commit messages.

But yes, we can proceed with:

(1) leave [1] as it is (with the fixups applied to mm-unstable already) and send
    v2 of [2]
(2) send a v3 for [1] that also includes [2]
(3) send a v3 of [1] and a separate v2 for [2]

Just let me know what you prefer. I'm fine with either of those. :)

[1] https://lore.kernel.org/linux-mm/20240722163111.4766-1-dakr@kernel.org/
[2] https://lore.kernel.org/linux-mm/20240730194214.31483-1-dakr@kernel.org/