On 3/31/26 06:18, Borislav Petkov wrote:
On Mon, Mar 30, 2026 at 04:25:26PM -0700, Rosen Penev wrote:
On Mon, Mar 30, 2026 at 3:32 PM Borislav Petkov <[email protected]> wrote:
On Mon, Mar 30, 2026 at 02:26:10PM -0700, Rosen Penev wrote:
Oh, hypothetical what-if. Yeah, pls drop all that gunk from commit messages
pls and simply concentrate on why the patch exists.
Not sure what you mean.
I mean this: a commit message should simply state why a patch exists. Here's
what I did with yours:
Convert struct mem_ctl_info to use flex array and use the new flex array
helpers to enable runtime bounds checking, including annotating the array
length member with __counted_by() for extra runtime analysis when
requested.
Move counter assignment immediately after allocation as required by
__counted_by().
This is misinformation and should be phrased differently[1]
-Gustavo
[1]
https://lore.kernel.org/linux-hardening/[email protected]/
Move memcpy() after the counter assignment so that it is initialized before
the first reference to the flex array, as the new attribute requires.
Looks great.
The idea is that when one reads the commit message months, or even years from
now - something we all have to do on a daily basis - it should have all the
necessary information why the change was done.
And nothing else. The emphasis being on the latter part. In this case, what
this should have been and what some tools can do when lines are magically
ordered doesn't really matter. The change must be worth to exist for itself.
In this case, runtime bounds checking, which is something we all want.
Applied, thanks.
