[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <974640be-a87e-5a46-3dcc-ba8dbf79c9cf@opensource.wdc.com>
Date: Thu, 6 Jan 2022 16:49:32 +0900
From: Damien Le Moal <damien.lemoal@...nsource.wdc.com>
To: Dan Carpenter <dan.carpenter@...cle.com>
Cc: Christophe JAILLET <christophe.jaillet@...adoo.fr>,
axboe@...nel.dk, chaitanya.kulkarni@....com, damien.lemoal@....com,
ming.lei@...hat.com, Johannes.Thumshirn@....com,
shinichiro.kawasaki@....com, jiangguoqing@...inos.cn,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] null_blk: Use bitmap_zalloc() when applicable
On 1/6/22 16:44, Dan Carpenter wrote:
> On Thu, Dec 30, 2021 at 11:28:28AM +0900, Damien Le Moal wrote:
>>>
>>> - tag_size = ALIGN(nq->queue_depth, BITS_PER_LONG) / BITS_PER_LONG;
>>> - nq->tag_map = kcalloc(tag_size, sizeof(unsigned long), GFP_KERNEL);
>>> + nq->tag_map = bitmap_zalloc(nq->queue_depth, GFP_KERNEL);
>>> if (!nq->tag_map) {
>>> kfree(nq->cmds);
>>> return -ENOMEM;
>>
>> Before this patch, tag_size would always be a multiple of BITS_PER_LONG.
>> Using bitmap_zalloc(), that alignment goes away, but I think this is OK.
>>
>
> It's still going to be a multiple of long. Bitmaps are always stored
> in longs.
Yes, I understand that. I was referring to tag_size, which was rounded
before. But tag_size is only a local variable and not the actual queue
depth, which is not rounded. I got confused :)
>
> regards,
> dan carpenter
>
--
Damien Le Moal
Western Digital Research
Powered by blists - more mailing lists