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] [thread-next>] [day] [month] [year] [list]
Message-ID: <4908d9a3-8b04-4808-8190-c1b602cba9dd@suse.cz>
Date: Wed, 31 Jul 2024 16:43:39 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Danilo Krummrich <dakr@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: 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 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.

> [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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ