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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240730141953.a30fa50c0ba060fe0a765730@linux-foundation.org>
Date: Tue, 30 Jul 2024 14:19:53 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Danilo Krummrich <dakr@...nel.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, 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.

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.