Messages in this thread | | | Subject | Re: [PATCH] xen-blkfront: Use the bitmap API when applicable | From | Christophe JAILLET <> | Date | Thu, 2 Dec 2021 20:07:17 +0100 |
| |
Le 02/12/2021 à 19:16, Joe Perches a écrit : > On Thu, 2021-12-02 at 19:12 +0100, Christophe JAILLET wrote: >> Le 02/12/2021 à 07:12, Juergen Gross a écrit : >>> On 01.12.21 22:10, Christophe JAILLET wrote: >>>> Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid >>>> some open-coded arithmetic in allocator arguments. >>>> >>>> Also change the corresponding 'kfree()' into 'bitmap_free()' to keep >>>> consistency. >>>> >>>> Use 'bitmap_copy()' to avoid an explicit 'memcpy()' > [] >>>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c > [] >>>> @@ -442,16 +442,14 @@ static int xlbd_reserve_minors(unsigned int >>>> minor, unsigned int nr) >>>> if (end > nr_minors) { >>>> unsigned long *bitmap, *old; >>>> - bitmap = kcalloc(BITS_TO_LONGS(end), sizeof(*bitmap), >>>> - GFP_KERNEL); >>>> + bitmap = bitmap_zalloc(end, GFP_KERNEL); >>>> if (bitmap == NULL) >>>> return -ENOMEM; >>>> spin_lock(&minor_lock); >>>> if (end > nr_minors) { >>>> old = minors; >>>> - memcpy(bitmap, minors, >>>> - BITS_TO_LONGS(nr_minors) * sizeof(*bitmap)); >>>> + bitmap_copy(bitmap, minors, nr_minors); >>>> minors = bitmap; >>>> nr_minors = BITS_TO_LONGS(end) * BITS_PER_LONG; > > nr_minors = end; > ? >
No, My understanding of the code is that if we lack space (end > nr_minors), we need to allocate more. In such a case, we want to keep track of what we have allocated, not what we needed. The "padding" bits in the "long align" allocation, can be used later.
first call ---------- end = 65 nr_minors = 63
--> we need some space --> we allocate 2 longs = 128 bits --> we now use 65 bits of these 128 bits
new call -------- end = 68 nr_minors = 128 (from previous call) --> no need to reallocate
CJ
| |