linux-kernel - [PATCH 0/2] scsi: lpfc: Cleanup some bitmap handling.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 24 Dec 2021 08:06:56 +0100
From:   Christophe JAILLET <christophe.jaillet@...adoo.fr>
To:     james.smart@...adcom.com, dick.kennedy@...adcom.com,
        jejb@...ux.ibm.com, martin.petersen@...cle.com
Cc:     linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel-janitors@...r.kernel.org,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>
Subject: [PATCH 0/2] scsi: lpfc: Cleanup some bitmap handling.

The 1st patch of this serie uses bitmap_zalloc() to simplify code.
The 2nd patch makes sure that the whole bitmap is cleared, should it need more
than 1 long.

However, this 'fcf_rr_bmask' is small (LPFC_SLI4_FCF_TBL_INDX_MAX = 32 bits), so
another option could be to use DECLARE_BITMAP instead of dynamic allocation.

This would simplify code (no more allocation and associated error handling) and
be slighly more efficient (1 less indirection when accessing the bitmap).
In the case the 2nd patch could also be removed (using bitmap_zero() would still
be cleaner (IMHO), but the actual memset+sizeof would work as expected)

Let me know if I should send a v2 with this other approach.

Christophe JAILLET (2):
  scsi: lpfc: Use bitmap_zalloc() when applicable
  scsi: lpfc: Make sure to completely clear some bitmaps

 drivers/scsi/lpfc/lpfc_hbadisc.c |  7 ++++---
 drivers/scsi/lpfc/lpfc_init.c    | 10 ++++------
 drivers/scsi/lpfc/lpfc_sli.c     |  3 +--
 3 files changed, 9 insertions(+), 11 deletions(-)

-- 
2.32.0