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

[Greg Kroah-Hartman]

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