On Wed, Mar 11, 2026 at 4:37 PM Bryan O'Donoghue <[email protected]> wrote: > > On 11/03/2026 23:23, Rosen Penev wrote: > > Change kzalloc + kcalloc to just kzalloc with a flexible array member. > > > > Add __counted_by for extra runtime analysis when requested. > > > > Move counting assignment immediately after allocation as required by > > __counted_by. > > > > Signed-off-by: Rosen Penev <[email protected]> > > Hi Rosen. > > Thanks for your patch. > > I have the same feedback as Greg gave you previously on this. > > Each line-item in your log should really be its own patch i.e. v3 should > be three patches > > [PATCH v3 1/3] Change kzalloc + kcalloc to just kzalloc with a flexible > array member. This is probably the only one worth anything. I'm getting requests elsewhere to add __counted_by though. > > [PATCH v3 2/3] Add __counted_by for extra runtime analysis when requested. > > [PATCH v3 3/3] Move counting assignment immediately after allocation as > required by __counted_by. 2 and 3 as you laid out should be the same. 2 without 3 breaks runtime analysis. > > Or something pretty close to that. > > There are several reasons for that > > 1. Bisectability > The ability to more easily bisect patches. > > 2. Logical separation > If a change deserves its own line-item in a patch > then that change almost certainly deserves its own patch. > > 3. Mixing stuff up in a big patch is confusing calling
20 insertions(+), 25 deletions(-) big is wild. > I look at a commit log and see lots of things going on in one go. > I as a reviewer or say someone tracking -stable and deciding which > patches to pull into my tree can't look at a patch a "just know" what > it is doing. > > So v3 should please > > - Have a cover letter > - Contain three patches one for each logical change Maybe some other time. > > Oh and reason 4 is the most important ! > > Patch count bragging rights ! That's just pointless churn. > > --- > bod
