Hi Everybody,
On 11/25/2021 7:59 AM, Alexei Starovoitov wrote:
On Wed, Nov 24, 2021 at 1:14 AM Song Liu <song@xxxxxxxxxx> wrote:
On Tue, Nov 23, 2021 at 8:49 AM James Morse <james.morse@xxxxxxx> wrote:
Hello,
On 23/11/2021 17:45, Song Liu wrote:
On Sat, Nov 20, 2021 at 6:55 AM Jakub Kicinski <kuba@xxxxxxxxxx> 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@xxxxxxxxxx/
Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
---
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@xxxxxx>
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@xxxxxxxxxx>
and probably the fastest is for Jakub to take it via net tree directly.
These responses seems to ignore the information provided by James.
How about just the hunk below. It is not needed by the other parts
removed and addresses the issue described in the changelog.
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -3,7 +3,6 @@
#define _LINUX_CACHEINFO_H
#include <linux/bitops.h>
-#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/smp.h>
Reinette
