linux-kernel - Re: [PATCH 1/2] lib/bitmap: move bitmap allocators for device to linux/device.h

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 8 Oct 2023 08:39:13 -0700
From:   Yury Norov <yury.norov@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Brendan Higgins <brendan.higgins@...ux.dev>,
        David Gow <davidgow@...gle.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        James Seo <james@...iv.tech>, Jason Baron <jbaron@...mai.com>,
        Kees Cook <keescook@...omium.org>,
        Kefeng Wang <wangkefeng.wang@...wei.com>,
        Marco Elver <elver@...gle.com>,
        Mark Brown <broonie@...nel.org>,
        Ming Lei <ming.lei@...hat.com>,
        Petr Tesarik <petr.tesarik.ext@...wei.com>,
        Rae Moar <rmoar@...gle.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 1/2] lib/bitmap: move bitmap allocators for device to
 linux/device.h

On Sun, Oct 08, 2023 at 06:53:49AM +0200, Greg Kroah-Hartman wrote:
> On Sat, Oct 07, 2023 at 04:35:09PM -0700, Yury Norov wrote:
> > The allocators are simple wrappers around bitmap_{alloc,free}().
> > So move them from bitmap to device sources.
> 
> No, they belong in the bitmap.h file, as they are devm_* versions of the
> same functions in this file.  They don't belong in the device.h file.

OK then. I don't thing that the functions are anything wrong, and
don't want to 'get rid of them' in any way.

But could you please elaborate? I'm not too familiar to devm_* things,
and to me devm_alloc/free() look similar to e.g.
vfio_dma_bitmap_alloc_all() or iova_bitmap_alloc(), which allocate
memory for bitmap + do some other initialization things.

And they all reside in corresponding subsystems. Why devm differs? 

> > Similarly to other device wrappers, turn them to static inlines
> > and place in header.
> 
> Why do these need to be inline functions?

Because they are small. devm_bitmap_free() and devm_bitmap_zalloc()
are pure one-line wrappers, and devm_bimap_alloc() is a 2 function
calls followed by conditionals, which is similar  to
__devm_add_action_or_reset() or devm_kmalloc_array() in the same file,
and much less than some other inliners in the source tree.

In my plans, I want to move bitmap_{z,}alloc/free() to linux/bitmap.h,
and that way devm_bitmap_alloc() together with other users would be
propagated __kmalloc_array() by compiler without generating pretty
useless call/ret's, and benefit from compile-time optimizations if
__builtin_constant_p() hits.

Maybe it's worth to do in this series.

Thanks,
Yury