[PATCH bpf] cacheinfo: move get_cpu_cacheinfo_id() back out

[Alexei Starovoitov]

On Wed, Nov 24, 2021 at 1:14 AM Song Liu <song at kernel.org> wrote:
>
> On Tue, Nov 23, 2021 at 8:49 AM James Morse <james.morse at arm.com> wrote:
> >
> > Hello,
> >
> > On 23/11/2021 17:45, Song Liu wrote:
> > > On Sat, Nov 20, 2021 at 6:55 AM Jakub Kicinski <kuba at kernel.org> wrote:
> > >>
> > >> This commit more or less reverts commit 709c4362725a ("cacheinfo:
> > >> Move resctrl's get_cache_id() to the cacheinfo header file").
> > >>
> > >> There are no users of the static inline helper outside of resctrl/core.c
> > >> and cpu.h is a pretty heavy include, it pulls in device.h etc. This
> > >> trips up architectures like riscv which want to access cacheinfo
> > >> in low level headers like elf.h.
> > >>
> > >> Link: https://lore.kernel.org/all/20211120035253.72074-1-kuba@kernel.org/
> > >> Signed-off-by: Jakub Kicinski <kuba at kernel.org>
> > >> ---
> >
> > >> x86 resctrl folks, does this look okay?
> > >>
> > >> I'd like to do some bpf header cleanups in -next which this is blocking.
> > >> How would you like to handle that? This change looks entirely harmless,
> > >> can I get an ack and take this via bpf/netdev to Linus ASAP so it
> > >> propagates to all trees?
> > >
> > > Does this patch target the bpf tree, or the bpf-next tree? If we want to unblock
> > > bpf header cleanup in -next, we can simply include it in a set for bpf-next.
> >
> >
> > Some background: this is part of the mpam tree that wires up resctrl for arm64. This patch
> > floated to the top and got merged with some cleanup as it was independent of the wider
> > resctrl changes.
> >
> > If the cpu.h include is the problem, I can't see what that is needed for. It almost
> > certainly came in with a lockdep annotation that got replaced by a comment instead.
>
> Thanks for the information.
>
> I can ack the patch for the patch itself.
>
> Acked-by: Song Liu <songliubraving at fb.com>
>
> But I am not sure whether we should ship it via bpf tree. It seems to
> me that the
> only reason we ship it via bpf tree is to get it to upstream ASAP?
>
> Alexei/Daniel/Andrii, what do you think about this?

I don't completely understand why it cannot go via -next along
with other patches, but if Jakub needs it asap here is my
Acked-by: Alexei Starovoitov <ast at kernel.org>
and probably the fastest is for Jakub to take it via net tree directly.