On Thu, Oct 20, 2022 at 8:20 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> The patch, while still fairly small, is a bit
> larger than one might expect from a simple s/GFP_KERNEL/GFP_ATOMIC/
> conversion because we added support for the function to be called with
> different gfp flags depending on the context, preserving GFP_KERNEL
> for those cases that can safely sleep.
Hmm.
So I've pulled this, but that patch actually makes it obvious that
there is only one single possible function for "convert->func", namely
that "convert_context()" function.
So why is that an indirect function call in the first place? That just
makes for slower (particularly in this age of indirect call
speculation costs), and bigger code, and only makes it harder to see
what is going on.
In the call-site, it looks like "Oh, this will call some
conversion-specific callback function".
In reality, there is no context-specific callback, there is only ever
convert_context().
Inefficient and misleading code. Not a great combination.
Linus
