Re: [linux-next:master] BUILD REGRESSION 8568bb2ccc278f344e6ac44af6ed010a90aa88dc
On Fri, Apr 5, 2024 at 8:37 AM kernel test robot wrote: > > tree/branch: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > branch HEAD: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc Add linux-next > specific files for 20240405 > > Error/Warning reports: > > https://lore.kernel.org/oe-kbuild-all/202404051333.7und7ppw-...@intel.com > https://lore.kernel.org/oe-kbuild-all/202404051423.eiaxlwhx-...@intel.com > https://lore.kernel.org/oe-kbuild-all/202404051659.aawukguq-...@intel.com > https://lore.kernel.org/oe-kbuild-all/202404052022.cwf2ilbp-...@intel.com > > Error/Warning: (recently discovered and may have been fixed) > > aarch64-linux-ld: kernel/bpf/verifier.c:20223:(.text+0xdbb4): undefined > reference to `__SCK__perf_snapshot_branch_stack' > aarch64-linux-ld: verifier.c:(.text+0x17c3c): undefined reference to > `__SCK__perf_snapshot_branch_stack' > drivers/i2c/busses/i2c-i801.c:1407:(.text+0x1d2ef4a): undefined reference to > `i2c_root_adapter' > kernel/bpf/verifier.c:20223:(.text+0xdba4): dangerous relocation: unsupported > relocation > loongarch64-linux-ld: kernel/bpf/verifier.c:20223:(.text+0xa818): undefined > reference to `__SCK__perf_snapshot_branch_stack' > loongarch64-linux-ld: verifier.c:(.text+0xa964): undefined reference to > `__SCK__perf_snapshot_branch_stack' > mips64el-linux-ld: verifier.c:(.text.do_misc_fixups+0xd9c): undefined > reference to `__SCK__perf_snapshot_branch_stack' > riscv32-linux-ld: section .data LMA [00369000,00907967] overlaps section > .text LMA [0007899c,01a6a6af] > s390-linux-ld: verifier.c:(.text+0x13038): undefined reference to > `__SCK__perf_snapshot_branch_stack' > verifier.c:(.text+0x17c14): relocation truncated to fit: > R_AARCH64_ADR_PREL_PG_HI21 against undefined symbol > `__SCK__perf_snapshot_branch_stack' > verifier.c:(.text+0xa960): undefined reference to > `__SCK__perf_snapshot_branch_stack' > verifier.c:(.text+0xadd0): dangerous relocation: unsupported relocation > verifier.c:(.text.do_misc_fixups+0xd98): undefined reference to > `__SCK__perf_snapshot_branch_stack' Fixed in bpf-next with commit: https://lore.kernel.org/all/20240405142637.577046-1-a...@kernel.org/
Re: [Intel-gfx] [PATCH bpf v2] treewide: add missing includes masked by cgroup -> bpf dependency
On Thu, Dec 2, 2021 at 11:11 PM Greg KH wrote: > > On Thu, Dec 02, 2021 at 12:34:00PM -0800, Jakub Kicinski wrote: > > cgroup.h (therefore swap.h, therefore half of the universe) > > includes bpf.h which in turn includes module.h and slab.h. > > Since we're about to get rid of that dependency we need > > to clean things up. > > > > v2: drop the cpu.h include from cacheinfo.h, it's not necessary > > and it makes riscv sensitive to ordering of include files. > > > > Link: https://lore.kernel.org/all/20211120035253.72074-1-k...@kernel.org/ > > # v1 > > Link: https://lore.kernel.org/all/20211120165528.197359-1-k...@kernel.org/ > > # cacheinfo discussion > > Acked-by: Krzysztof Wilczyński > > Acked-by: Peter Chen > > Acked-by: SeongJae Park > > Acked-by: Jani Nikula > > Signed-off-by: Jakub Kicinski > > Acked-by: Greg Kroah-Hartman I'm not sure how to test that it helps to reduce build deps, but it builds and passes tests, so applied to bpf tree. Jakub, you'll soon get it back via bpf tree PR :)
Re: [Intel-gfx] [PATCH v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
wrote:
>
>
> On 21.01.2020 17:43, Stephen Smalley wrote:
> > On 1/20/20 6:23 AM, Alexey Budankov wrote:
> >>
> >> Introduce CAP_PERFMON capability designed to secure system performance
> >> monitoring and observability operations so that CAP_PERFMON would assist
> >> CAP_SYS_ADMIN capability in its governing role for perf_events, i915_perf
> >> and other performance monitoring and observability subsystems.
> >>
> >> CAP_PERFMON intends to harden system security and integrity during system
> >> performance monitoring and observability operations by decreasing attack
> >> surface that is available to a CAP_SYS_ADMIN privileged process [1].
> >> Providing access to system performance monitoring and observability
> >> operations under CAP_PERFMON capability singly, without the rest of
> >> CAP_SYS_ADMIN credentials, excludes chances to misuse the credentials and
> >> makes operation more secure.
> >>
> >> CAP_PERFMON intends to take over CAP_SYS_ADMIN credentials related to
> >> system performance monitoring and observability operations and balance
> >> amount of CAP_SYS_ADMIN credentials following the recommendations in the
> >> capabilities man page [1] for CAP_SYS_ADMIN: "Note: this capability is
> >> overloaded; see Notes to kernel developers, below."
> >>
> >> Although the software running under CAP_PERFMON can not ensure avoidance
> >> of related hardware issues, the software can still mitigate these issues
> >> following the official embargoed hardware issues mitigation procedure [2].
> >> The bugs in the software itself could be fixed following the standard
> >> kernel development process [3] to maintain and harden security of system
> >> performance monitoring and observability operations.
> >>
> >> [1] http://man7.org/linux/man-pages/man7/capabilities.7.html
> >> [2]
> >> https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html
> >> [3] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
> >>
> >> Signed-off-by: Alexey Budankov
> >> ---
> >> include/linux/capability.h | 12
> >> include/uapi/linux/capability.h | 8 +++-
> >> security/selinux/include/classmap.h | 4 ++--
> >> 3 files changed, 21 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/include/linux/capability.h b/include/linux/capability.h
> >> index ecce0f43c73a..8784969d91e1 100644
> >> --- a/include/linux/capability.h
> >> +++ b/include/linux/capability.h
> >> @@ -251,6 +251,18 @@ extern bool privileged_wrt_inode_uidgid(struct
> >> user_namespace *ns, const struct
> >> extern bool capable_wrt_inode_uidgid(const struct inode *inode, int cap);
> >> extern bool file_ns_capable(const struct file *file, struct
> >> user_namespace *ns, int cap);
> >> extern bool ptracer_capable(struct task_struct *tsk, struct
> >> user_namespace *ns);
> >> +static inline bool perfmon_capable(void)
> >> +{
> >> +struct user_namespace *ns = &init_user_ns;
> >> +
> >> +if (ns_capable_noaudit(ns, CAP_PERFMON))
> >> +return ns_capable(ns, CAP_PERFMON);
> >> +
> >> +if (ns_capable_noaudit(ns, CAP_SYS_ADMIN))
> >> +return ns_capable(ns, CAP_SYS_ADMIN);
> >> +
> >> +return false;
> >> +}
> >
> > Why _noaudit()? Normally only used when a permission failure is non-fatal
> > to the operation. Otherwise, we want the audit message.
>
> Some of ideas from v4 review.
well, in the requested changes form v4 I wrote:
return capable(CAP_PERFMON);
instead of
return false;
That's what Andy suggested earlier for CAP_BPF.
I think that should resolve Stephen's concern.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
On Tue, Jun 11, 2019 at 5:00 PM Shyam Saini wrote: > > Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD > and FIELD_SIZEOF which are used to calculate the size of a member of > structure, so to bring uniformity in entire kernel source tree lets use > FIELD_SIZEOF and replace all occurrences of other two macros with this. > > For this purpose, redefine FIELD_SIZEOF in include/linux/stddef.h and > tools/testing/selftests/bpf/bpf_util.h and remove its defination from > include/linux/kernel.h please dont. bpf_util.h is a user space header. Please leave it as-is. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] include: linux: Regularise the use of FIELD_SIZEOF macro
On Sun, Apr 14, 2019 at 2:15 AM Shyam Saini wrote: > > Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD > and FIELD_SIZEOF which are used to calculate the size of a member of > structure, so to bring uniformity in entire kernel source tree lets use > FIELD_SIZEOF and replace all occurrences of other two macros with this. > > For this purpose, redefine FIELD_SIZEOF in include/linux/stddef.h and > tools/testing/selftests/bpf/bpf_util.h and remove its defination from > include/linux/kernel.h > > Signed-off-by: Shyam Saini > --- > arch/arm64/include/asm/processor.h | 10 +- > arch/mips/cavium-octeon/executive/cvmx-bootmem.c | 2 +- > drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- > drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c | 4 ++-- > fs/befs/linuxvfs.c | 2 +- > fs/ext2/super.c| 2 +- > fs/ext4/super.c| 2 +- > fs/freevxfs/vxfs_super.c | 2 +- > fs/orangefs/super.c| 2 +- > fs/ufs/super.c | 2 +- > include/linux/kernel.h | 9 - > include/linux/slab.h | 2 +- > include/linux/stddef.h | 11 ++- > kernel/fork.c | 2 +- > kernel/utsname.c | 2 +- > net/caif/caif_socket.c | 2 +- > net/core/skbuff.c | 2 +- > net/ipv4/raw.c | 2 +- > net/ipv6/raw.c | 2 +- > net/sctp/socket.c | 4 ++-- > tools/testing/selftests/bpf/bpf_util.h | 11 ++- tools/ directory is for user space pieces that don't include kernel's include. I bet your pathes break the user space builds. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data
On 3/13/18 3:13 PM, Tejun Heo wrote: Hello, On Tue, Mar 13, 2018 at 02:47:45PM -0700, Alexei Starovoitov wrote: it has to be zero lookups. If idr lookup is involved, it's cleaner to add idr as new bpf map type and use cgroup ino as an id. Oh, idr (or rather ida) is just to allocate the key, once the key is there it pretty much should boil down to sth like rcu_read_lock(); table = rcu_deref(cgrp->table); if (key < table->len) ret = table[key]; else ret = NULL; rcu_read_unlock(); Depending on the requirements, we can get rid of the table->len check by making key alloc path more expensive (ie. give out key only after table extension is fully done and propagated). just like two bpf progs can be attached to the same cgroup the same bpf prog can be attached to multiple cgroups. If we use ida to allocate an id and store it bpf->aux->cgroup_table_key to later do: cgrp->table[bpf->aux->cgroup_table_key] this id==key would need to valid across multiple cgroups which complicates things a lot. It feels that we need something similar to compute_effective_progs() but for this scratch buffers. Then at the time of BPF_PROG_RUN_ARRAY supply corresponding scratch buffer for every program. Next to cgrp->bpf.effective[type] have similar array of pointers to scratch buffers. We probably need to think through how the same mechanism can be used for per-socket scratch buffers. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data
On 3/13/18 2:37 PM, Roman Gushchin wrote:
On Tue, Mar 13, 2018 at 02:27:58PM -0700, Alexei Starovoitov wrote:
On 3/13/18 1:50 PM, Tejun Heo wrote:
Hello, Matt.
cc'ing Roman and Alexei.
On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote:
There are cases where other parts of the kernel may wish to store data
associated with individual cgroups without building a full cgroup
controller. Let's add interfaces to allow them to register and lookup
this private data for individual cgroups.
A kernel system (e.g., a driver) that wishes to register private data
for a cgroup will do so by subclassing the 'struct cgroup_priv'
structure to describe the necessary data to store. Before registering a
private data structure to a cgroup, the caller should fill in the 'key'
and 'free' fields of the base cgroup_priv structure.
* 'key' should be a unique void* that will act as a key for future
privdata lookups/removals. Note that this allows drivers to store
per-device private data for a cgroup by using a device pointer as a key.
* 'free' should be a function pointer to a function that may be used
to destroy the private data. This function will be called
automatically if the underlying cgroup is destroyed.
This feature turned out to have more users than I originally
anticipated and bpf also wants something like this to track network
states. The requirements are pretty similar but not quite the same.
The extra requirements are...
* Lookup must be really cheap. Probably using pointer hash or walking
list isn't great, so maybe idr based lookup + RCU protected index
table per cgroup?
* It should support both regular memory and percpu pointers. Given
that what cgroup does is pretty much cgroup:key -> pointer lookup,
it's mostly about getting the interface right so that it's not too
error-prone.
from bpf side there should be _zero_ lookups.
If bpf do a lookup it can equally use its own map to do that.
From bpf program point of view it will look like:
struct my_data {
u64 a;
u32 b;
} *ptr;
ptr = bpf_get_cgroup_buf(skb, sizeof(struct my_data));
bpf_get_cgroup_buf() is lookup-free. Worst case it will do pointer
dereferences
skb->sk->sk_cgrp_data->val to get to cgroup and from cgroup to get pointer
to the buffer.
Having strictly one buffer per-cgroup sounds very limiting.
What if two independent bpf programs start using it?
In good case it may be optimized (inlined) by the verifier into absolute
address of that cgroup scratch buffer at attach time.
Maybe we can have an idr-based index table (as Tejun suggested above),
but avoid performance penalty by optimizing the lookup out at the attach time?
it has to be zero lookups. If idr lookup is involved, it's cleaner
to add idr as new bpf map type and use cgroup ino as an id.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data
On 3/13/18 1:50 PM, Tejun Heo wrote:
Hello, Matt.
cc'ing Roman and Alexei.
On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote:
There are cases where other parts of the kernel may wish to store data
associated with individual cgroups without building a full cgroup
controller. Let's add interfaces to allow them to register and lookup
this private data for individual cgroups.
A kernel system (e.g., a driver) that wishes to register private data
for a cgroup will do so by subclassing the 'struct cgroup_priv'
structure to describe the necessary data to store. Before registering a
private data structure to a cgroup, the caller should fill in the 'key'
and 'free' fields of the base cgroup_priv structure.
* 'key' should be a unique void* that will act as a key for future
privdata lookups/removals. Note that this allows drivers to store
per-device private data for a cgroup by using a device pointer as a key.
* 'free' should be a function pointer to a function that may be used
to destroy the private data. This function will be called
automatically if the underlying cgroup is destroyed.
This feature turned out to have more users than I originally
anticipated and bpf also wants something like this to track network
states. The requirements are pretty similar but not quite the same.
The extra requirements are...
* Lookup must be really cheap. Probably using pointer hash or walking
list isn't great, so maybe idr based lookup + RCU protected index
table per cgroup?
* It should support both regular memory and percpu pointers. Given
that what cgroup does is pretty much cgroup:key -> pointer lookup,
it's mostly about getting the interface right so that it's not too
error-prone.
from bpf side there should be _zero_ lookups.
If bpf do a lookup it can equally use its own map to do that.
From bpf program point of view it will look like:
struct my_data {
u64 a;
u32 b;
} *ptr;
ptr = bpf_get_cgroup_buf(skb, sizeof(struct my_data));
bpf_get_cgroup_buf() is lookup-free. Worst case it will do pointer
dereferences
skb->sk->sk_cgrp_data->val to get to cgroup and from cgroup to get
pointer to the buffer.
In good case it may be optimized (inlined) by the verifier into absolute
address of that cgroup scratch buffer at attach time.
sizeof(struct my_data) will be seen by verifier and it will propagate it
into prog->aux.
Later at prog attach time the kernel will request allocation via
cgroup_malloc(cgrp)
This scratch memory will be available per-cgroup and can be further
divided by the bpf program.
The bound checks will be done statically by the verifier similar to map
values.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
