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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2023100840-silk-quarterly-f694@gregkh>
Date:   Sun, 8 Oct 2023 18:31:42 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Yury Norov <yury.norov@...il.com>
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 08:39:13AM -0700, Yury Norov wrote:
> 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? 

They are just "devm" versions of the normal functions, so they belong
next to those normal functions as well.

> > > 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.

Are you sure this works properly?  the _free functions for devm_* calls
are set as function pointers and you just passed in a function pointer
to an inline function in your patch.  How is that going to work?  Will
you get even more versions than the original one had (hint, I think you
will, one per file it is called in...)

> 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.

Does that really matter for _alloc() calls?  These should not be on a
fast path (or at least the devm_*() ones should not be.  What workload
has this as being a bottleneck?

And remember, in modern systems with retbleed mitigations enabled, there
are no 'ret' calls in the kernel at all!

thanks,

greg k-h