public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: David Laight <david.laight.linux@gmail.com>
Cc: "Qu Wenruo" <quwenruo.btrfs@gmx.com>,
	"Miquel Sabaté Solà" <mssola@mssola.com>,
	dsterba@suse.com, clm@fb.com, naohiro.aota@wdc.com,
	linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	kees@kernel.org
Subject: Re: [PATCH] btrfs: replace kcalloc() calls to kzalloc_objs()
Date: Wed, 25 Feb 2026 15:44:46 +0100	[thread overview]
Message-ID: <20260225144446.GE26902@twin.jikos.cz> (raw)
In-Reply-To: <20260224145555.44a8096d@pumpkin>

On Tue, Feb 24, 2026 at 02:55:55PM +0000, David Laight wrote:
> On Tue, 24 Feb 2026 15:07:10 +1030
> Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> 
> > 在 2026/2/24 10:14, Miquel Sabaté Solà 写道:
> > > Commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and family")
> > > introduced, among many others, the kzalloc_objs() helper, which has some
> > > benefits over kcalloc().
> > > 
> > > Cc: Kees Cook <kees@kernel.org>
> > > Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
> > > ---
> > >   fs/btrfs/block-group.c       | 2 +-
> > >   fs/btrfs/raid56.c            | 8 ++++----
> > >   fs/btrfs/tests/zoned-tests.c | 2 +-
> > >   fs/btrfs/volumes.c           | 6 ++----
> > >   fs/btrfs/zoned.c             | 5 ++---
> > >   5 files changed, 10 insertions(+), 13 deletions(-)
> > > 
> > > diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
> > > index 37bea850b3f0..8d85b4707690 100644
> > > --- a/fs/btrfs/block-group.c
> > > +++ b/fs/btrfs/block-group.c
> > > @@ -2239,7 +2239,7 @@ int btrfs_rmap_block(struct btrfs_fs_info *fs_info, u64 chunk_start,
> > >   	if (map->type & BTRFS_BLOCK_GROUP_RAID56_MASK)
> > >   		io_stripe_size = btrfs_stripe_nr_to_offset(nr_data_stripes(map));
> > >   
> > > -	buf = kcalloc(map->num_stripes, sizeof(u64), GFP_NOFS);
> > > +	buf = kzalloc_objs(*buf, map->num_stripes, GFP_NOFS);  
> > 
> > Not sure if we should use *buf for the type.
> > 
> > I still remember we had some bugs related to incorrect type usage.
> 
> The global change really ought to have used u64 to add the type-check.
> Otherwise it will have added 'very hard to find' bugs in the very code
> it is trying to make better.
> 
> Using *buf for the type might be a reasonable pattern for new code.

I find this a bit contradictory: I agree that using *buf as the argument
can cause bugs hard to find, yet the next sentence recommends to use it.

This kzalloc_obj way is new I'm analyzing what would be a good pattern
and so far I don't like the "*buf" style of 1st argument. As the
function is really a macro it does not dereference it but it still
appears as it does.

Writing the type explicitly looks still more like a C to me. Types in
arguments are in helpers like container_of or rb_entry and it makes it
obvious that there's something special while for the kzalloc_obj I need
to remember it.

The whole thing would read better as "allocate object of type", so I'm
probably going to convert it to this pattern in btrfs code.

  reply	other threads:[~2026-02-25 14:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 23:44 [PATCH] btrfs: replace kcalloc() calls to kzalloc_objs() Miquel Sabaté Solà
2026-02-24  0:06 ` Kees Cook
2026-02-24  6:23   ` Miquel Sabaté Solà
     [not found]   ` <699d43e6.170a0220.3a6e96.a235SMTPIN_ADDED_BROKEN@mx.google.com>
2026-02-24 11:29     ` David Sterba
2026-02-24 12:23       ` Miquel Sabaté Solà
2026-02-24  4:37 ` Qu Wenruo
2026-02-24  4:42   ` Qu Wenruo
2026-02-24 13:52     ` David Sterba
2026-02-24  6:36   ` Miquel Sabaté Solà
     [not found]   ` <699d4704.050a0220.1a6450.86d7SMTPIN_ADDED_BROKEN@mx.google.com>
2026-02-24  6:48     ` Qu Wenruo
2026-02-24  8:59       ` Miquel Sabaté Solà
2026-02-24 14:55   ` David Laight
2026-02-25 14:44     ` David Sterba [this message]
2026-02-25 17:11       ` David Laight
2026-02-24  6:32 ` Johannes Thumshirn
2026-02-24  6:46   ` Miquel Sabaté Solà
2026-02-24  6:54     ` Qu Wenruo
2026-02-24  9:04       ` Miquel Sabaté Solà

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260225144446.GE26902@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=clm@fb.com \
    --cc=david.laight.linux@gmail.com \
    --cc=dsterba@suse.com \
    --cc=kees@kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mssola@mssola.com \
    --cc=naohiro.aota@wdc.com \
    --cc=quwenruo.btrfs@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox