| Message ID | 4afa3f71e66c941c660627c7f5b0223b51968ebb.1637961191.git.christophe.jaillet@wanadoo.fr (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/3] scsi: hisi_sas: Use devm_bitmap_zalloc() when applicable | expand |
On 26/11/2021 21:15, Christophe JAILLET wrote: > 'hisi_hba->slot_index_tags' is a bitmap. So use 'devm_bitmap_zalloc()' to > simplify code, improve the semantic and avoid some open-coded arithmetic > in allocator arguments. > > Signed-off-by: Christophe JAILLET<christophe.jaillet@wanadoo.fr> Acked-by: John Garry <john.garry@huawei.com> > --- > The use of 's' is questionable here. I've left it because it looks more > consistent this way with the surrounding code. > > Can it be an issue to have the length of the allocated bitmap not being > a multiple of sizeof(long)? The driver does not rely on that (allocated bitmap being a multiple of sizeof(long)), but the size is 4096 bits, which would be a multiple of sizeof(long) Thanks, John > I guess that there is some kind of 'rounding' done by the memory allocator > to keep some alignment, so I think that the previous code is safe (but not > logical). > If this is not the case, there is a potential out of bound bug related to > the bitmap API that expect to access only longs (which is not necessarily > the case here).
Christophe, > 'hisi_hba->slot_index_tags' is a bitmap. So use 'devm_bitmap_zalloc()' to > simplify code, improve the semantic and avoid some open-coded arithmetic > in allocator arguments. Applied to 5.17/scsi-staging, thanks!
On Fri, 26 Nov 2021 22:15:21 +0100, Christophe JAILLET wrote: > 'hisi_hba->slot_index_tags' is a bitmap. So use 'devm_bitmap_zalloc()' to > simplify code, improve the semantic and avoid some open-coded arithmetic > in allocator arguments. > > Applied to 5.17/scsi-queue, thanks! [1/3] scsi: hisi_sas: Use devm_bitmap_zalloc() when applicable https://git.kernel.org/mkp/scsi/c/54585ec62fbd [2/3] scsi: hisi_sas: Remove some useless code in 'hisi_sas_alloc()' https://git.kernel.org/mkp/scsi/c/d43efddf6271 [3/3] scsi: hisi_sas: Use non-atomic bitmap functions when possible https://git.kernel.org/mkp/scsi/c/4d6942e2666e
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c index f206c433de32..6ecb42d5ce81 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_main.c +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c @@ -2516,9 +2516,8 @@ int hisi_sas_alloc(struct hisi_hba *hisi_hba) if (!hisi_hba->breakpoint) goto err_out; - hisi_hba->slot_index_count = max_command_entries; - s = hisi_hba->slot_index_count / BITS_PER_BYTE; - hisi_hba->slot_index_tags = devm_kzalloc(dev, s, GFP_KERNEL); + s = hisi_hba->slot_index_count = max_command_entries; + hisi_hba->slot_index_tags = devm_bitmap_zalloc(dev, s, GFP_KERNEL); if (!hisi_hba->slot_index_tags) goto err_out;
'hisi_hba->slot_index_tags' is a bitmap. So use 'devm_bitmap_zalloc()' to simplify code, improve the semantic and avoid some open-coded arithmetic in allocator arguments. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> --- The use of 's' is questionable here. I've left it because it looks more consistent this way with the surrounding code. Can it be an issue to have the length of the allocated bitmap not being a multiple of sizeof(long)? I guess that there is some kind of 'rounding' done by the memory allocator to keep some alignment, so I think that the previous code is safe (but not logical). If this is not the case, there is a potential out of bound bug related to the bitmap API that expect to access only longs (which is not necessarily the case here). --- drivers/scsi/hisi_sas/hisi_sas_main.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)