1. Patchew
  2. linux
  3. [RFC PATCH v10 mm-new 0/9] mm, bpf: BPF-MM, BPF-THP
  4. View patch

[RFC PATCH v10 mm-new 6/9] bpf: mark mm->owner as __safe_rcu_or_null

Yafang Shao posted 9 patches 2 months ago
There is a newer version of this series
[RFC PATCH v10 mm-new 6/9] bpf: mark mm->owner as __safe_rcu_or_null
Posted by Yafang Shao 2 months ago 
When CONFIG_MEMCG is enabled, we can access mm->owner under RCU. The
owner can be NULL. With this change, BPF helpers can safely access
mm->owner to retrieve the associated task from the mm. We can then make
policy decision based on the task attribute.

The typical use case is as follows,

  bpf_rcu_read_lock(); // rcu lock must be held for rcu trusted field
  @owner = @mm->owner; // mm_struct::owner is rcu trusted or null
  if (!@owner)
      goto out;

  /* Do something based on the task attribute */

out:
  bpf_rcu_read_unlock();

Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
 kernel/bpf/verifier.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index c4f69a9e9af6..d400e18ee31e 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -7123,6 +7123,9 @@ BTF_TYPE_SAFE_RCU(struct cgroup_subsys_state) {
 /* RCU trusted: these fields are trusted in RCU CS and can be NULL */
 BTF_TYPE_SAFE_RCU_OR_NULL(struct mm_struct) {
 	struct file __rcu *exe_file;
+#ifdef CONFIG_MEMCG
+	struct task_struct __rcu *owner;
+#endif
 };
 
 /* skb->sk, req->sk are not RCU protected, but we mark them as such
-- 
2.47.3
Re: [RFC PATCH v10 mm-new 6/9] bpf: mark mm->owner as __safe_rcu_or_null
Posted by Andrii Nakryiko 2 months ago 
On Wed, Oct 15, 2025 at 7:18 AM Yafang Shao <laoar.shao@gmail.com> wrote:
>
> When CONFIG_MEMCG is enabled, we can access mm->owner under RCU. The
> owner can be NULL. With this change, BPF helpers can safely access
> mm->owner to retrieve the associated task from the mm. We can then make
> policy decision based on the task attribute.
>
> The typical use case is as follows,
>
>   bpf_rcu_read_lock(); // rcu lock must be held for rcu trusted field
>   @owner = @mm->owner; // mm_struct::owner is rcu trusted or null
>   if (!@owner)
>       goto out;
>
>   /* Do something based on the task attribute */
>
> out:
>   bpf_rcu_read_unlock();
>
> Suggested-by: Andrii Nakryiko <andrii@kernel.org>
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---
>  kernel/bpf/verifier.c | 3 +++
>  1 file changed, 3 insertions(+)
>

I thought you were going to send this and next patches outside of your
thp patch set to land them sooner, as they don't have dependency on
the rest of the patches and are useful on their own?

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index c4f69a9e9af6..d400e18ee31e 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -7123,6 +7123,9 @@ BTF_TYPE_SAFE_RCU(struct cgroup_subsys_state) {
>  /* RCU trusted: these fields are trusted in RCU CS and can be NULL */
>  BTF_TYPE_SAFE_RCU_OR_NULL(struct mm_struct) {
>         struct file __rcu *exe_file;
> +#ifdef CONFIG_MEMCG
> +       struct task_struct __rcu *owner;
> +#endif
>  };
>
>  /* skb->sk, req->sk are not RCU protected, but we mark them as such
> --
> 2.47.3
>
Re: [RFC PATCH v10 mm-new 6/9] bpf: mark mm->owner as __safe_rcu_or_null
Posted by Yafang Shao 2 months ago 
On Thu, Oct 16, 2025 at 12:36 AM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Wed, Oct 15, 2025 at 7:18 AM Yafang Shao <laoar.shao@gmail.com> wrote:
> >
> > When CONFIG_MEMCG is enabled, we can access mm->owner under RCU. The
> > owner can be NULL. With this change, BPF helpers can safely access
> > mm->owner to retrieve the associated task from the mm. We can then make
> > policy decision based on the task attribute.
> >
> > The typical use case is as follows,
> >
> >   bpf_rcu_read_lock(); // rcu lock must be held for rcu trusted field
> >   @owner = @mm->owner; // mm_struct::owner is rcu trusted or null
> >   if (!@owner)
> >       goto out;
> >
> >   /* Do something based on the task attribute */
> >
> > out:
> >   bpf_rcu_read_unlock();
> >
> > Suggested-by: Andrii Nakryiko <andrii@kernel.org>
> > Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> > Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > ---
> >  kernel/bpf/verifier.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
>
> I thought you were going to send this and next patches outside of your
> thp patch set to land them sooner, as they don't have dependency on
> the rest of the patches and are useful on their own?

Thanks for your reminder.
They have been sent separately:

  https://lore.kernel.org/bpf/20251016063929.13830-1-laoar.shao@gmail.com/

-- 
Regards
Yafang
Re: [RFC PATCH v10 mm-new 6/9] bpf: mark mm->owner as __safe_rcu_or_null
Posted by Lorenzo Stoakes 2 months ago 
On Thu, Oct 16, 2025 at 02:42:43PM +0800, Yafang Shao wrote:
> On Thu, Oct 16, 2025 at 12:36 AM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Wed, Oct 15, 2025 at 7:18 AM Yafang Shao <laoar.shao@gmail.com> wrote:
> > >
> > > When CONFIG_MEMCG is enabled, we can access mm->owner under RCU. The
> > > owner can be NULL. With this change, BPF helpers can safely access
> > > mm->owner to retrieve the associated task from the mm. We can then make
> > > policy decision based on the task attribute.
> > >
> > > The typical use case is as follows,
> > >
> > >   bpf_rcu_read_lock(); // rcu lock must be held for rcu trusted field
> > >   @owner = @mm->owner; // mm_struct::owner is rcu trusted or null
> > >   if (!@owner)
> > >       goto out;
> > >
> > >   /* Do something based on the task attribute */
> > >
> > > out:
> > >   bpf_rcu_read_unlock();
> > >
> > > Suggested-by: Andrii Nakryiko <andrii@kernel.org>
> > > Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> > > Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > ---
> > >  kernel/bpf/verifier.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> >
> > I thought you were going to send this and next patches outside of your
> > thp patch set to land them sooner, as they don't have dependency on
> > the rest of the patches and are useful on their own?
>
> Thanks for your reminder.
> They have been sent separately:
>
>   https://lore.kernel.org/bpf/20251016063929.13830-1-laoar.shao@gmail.com/

Could we respin this as a v2 without them then please so we can sensibly keep
the two separate?

Thanks!

>
> --
> Regards
> Yafang

I do intend to have a look through the various conversations on this, just
catching up after 2 weeks vacation :) in the kernel this is an eternity, even
during the merge window it seems :P

Cheers, Lorenzo
Re: [RFC PATCH v10 mm-new 6/9] bpf: mark mm->owner as __safe_rcu_or_null
Posted by Yafang Shao 2 months ago 
On Thu, Oct 16, 2025 at 3:21 PM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> On Thu, Oct 16, 2025 at 02:42:43PM +0800, Yafang Shao wrote:
> > On Thu, Oct 16, 2025 at 12:36 AM Andrii Nakryiko
> > <andrii.nakryiko@gmail.com> wrote:
> > >
> > > On Wed, Oct 15, 2025 at 7:18 AM Yafang Shao <laoar.shao@gmail.com> wrote:
> > > >
> > > > When CONFIG_MEMCG is enabled, we can access mm->owner under RCU. The
> > > > owner can be NULL. With this change, BPF helpers can safely access
> > > > mm->owner to retrieve the associated task from the mm. We can then make
> > > > policy decision based on the task attribute.
> > > >
> > > > The typical use case is as follows,
> > > >
> > > >   bpf_rcu_read_lock(); // rcu lock must be held for rcu trusted field
> > > >   @owner = @mm->owner; // mm_struct::owner is rcu trusted or null
> > > >   if (!@owner)
> > > >       goto out;
> > > >
> > > >   /* Do something based on the task attribute */
> > > >
> > > > out:
> > > >   bpf_rcu_read_unlock();
> > > >
> > > > Suggested-by: Andrii Nakryiko <andrii@kernel.org>
> > > > Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> > > > Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > > ---
> > > >  kernel/bpf/verifier.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > >
> > >
> > > I thought you were going to send this and next patches outside of your
> > > thp patch set to land them sooner, as they don't have dependency on
> > > the rest of the patches and are useful on their own?
> >
> > Thanks for your reminder.
> > They have been sent separately:
> >
> >   https://lore.kernel.org/bpf/20251016063929.13830-1-laoar.shao@gmail.com/
>
> Could we respin this as a v2 without them then please so we can sensibly keep
> the two separate?

Sure, I will send a v2.

>
> Thanks!
>
> >
> > --
> > Regards
> > Yafang
>
> I do intend to have a look through the various conversations on this, just
> catching up after 2 weeks vacation :) in the kernel this is an eternity, even
> during the merge window it seems :P

Huh, we've been refactoring a bit too fast and furious since your last
review ;-)

-- 
Regards
Yafang

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.