All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>,
	"Tejun Heo" <tj@kernel.org>, "David Vernet" <void@manifault.com>,
	"Andrea Righi" <arighi@nvidia.com>,
	"Changwoo Min" <changwoo@igalia.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	"Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Thomas Gleixner" <tglx@kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Emil Tsalapatis" <emil@etsalapatis.com>,
	<sched-ext@lists.linux.dev>, <bpf@vger.kernel.org>,
	<x86@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
	<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/8] bpf: Recover arena kernel faults with scratch page
Date: Thu, 28 May 2026 14:30:28 -0700	[thread overview]
Message-ID: <DIUMP21RASZI.2VNQV45RIL209@gmail.com> (raw)
In-Reply-To: <7fd673df-22f3-4d70-a779-ea0b878188b3@kernel.org>

On Tue May 26, 2026 at 5:45 AM PDT, David Hildenbrand (Arm) wrote:
>
> There is still the chance that apply_range_set_cb() could race with scratch
> insertion, right?

yes, it can race, but the fix is to remove only:

-       /* sanity check */
-       if (unlikely(!pte_none(ptep_get(pte))))
-               return -EBUSY;

It was sanity check, now it's simply in the way.
It should do set_pte_at() unconditionally.
It's totally fine to set it to proper page instead of scratch or empty.

Tejun,
do you mind sending a patch to remove these 3 lines or should I do it?

Changing topic. re: zap_vma_range() issue.
It's not forgotten, just complicated, since we can't just take
mmap_read_lock under arena->lock, since arena_vm_close() 
is called with mmap_write_lock held and it takes arena->lock.
Will figure something out.

> Shouldn't we also be using ptep_try_set() there?
>
> The nasty thing is handling whether ptep_try_set() actually works.
>
> Something like the following on top, maybe?
>
>
> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
> index 49a8f7b1beef5..086bea3f3698e 100644
> --- a/kernel/bpf/arena.c
> +++ b/kernel/bpf/arena.c
> @@ -122,19 +122,27 @@ static int apply_range_set_cb(pte_t *pte, unsigned long
> addr, void *data)
>  {
>         struct apply_range_data *d = data;
>         struct page *page;
> +       pte_t pteval;
>
>         if (!data)
>                 return 0;
> -       /* sanity check */
> -       if (unlikely(!pte_none(ptep_get(pte))))
> -               return -EBUSY;
>
>         page = d->pages[d->i];
>         /* paranoia, similar to vmap_pages_pte_range() */
>         if (WARN_ON_ONCE(!pfn_valid(page_to_pfn(page))))
>                 return -EINVAL;
>
> -       set_pte_at(&init_mm, addr, pte, mk_pte(page, PAGE_KERNEL));
> +       pteval = mk_pte(page, PAGE_KERNEL);
> +#ifdef ptep_try_set
> +       if (unlikely(!ptep_try_set(pte, pteval)))
> +               return -EBUSY;
> +#else
> +       if (unlikely(!pte_none(ptep_get(pte))))
> +               return -EBUSY;
> +
> +       set_pte_at(&init_mm, addr, pte, pteval);
> +#endif
>         d->i++;
>         return 0;
>  }



  reply	other threads:[~2026-05-28 21:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-22 17:22 [PATCHSET v4 sched_ext/for-7.2] bpf/arena: Direct kernel-side access Tejun Heo
2026-05-22 17:22 ` [PATCH 1/8] mm: Add ptep_try_set() for lockless empty-slot installs Tejun Heo
2026-05-22 22:07   ` David Hildenbrand (Arm)
2026-05-25 15:50   ` patchwork-bot+netdevbpf
2026-05-22 17:22 ` [PATCH 2/8] bpf: Recover arena kernel faults with scratch page Tejun Heo
2026-05-26 12:45   ` David Hildenbrand (Arm)
2026-05-28 21:30     ` Alexei Starovoitov [this message]
2026-05-29 18:12       ` Tejun Heo
2026-05-29 18:38         ` Alexei Starovoitov
2026-05-29 18:44           ` Tejun Heo
2026-05-31 17:47             ` Tejun Heo
2026-05-31 18:58               ` David Hildenbrand (Arm)
2026-06-01  0:16               ` Alexei Starovoitov
2026-05-22 17:22 ` [PATCH 3/8] bpf: Add sleepable variant of bpf_arena_alloc_pages for kernel callers Tejun Heo
2026-05-22 17:22 ` [PATCH 4/8] bpf: Add bpf_struct_ops_for_each_prog() Tejun Heo
2026-05-22 17:22 ` [PATCH 5/8] bpf/arena: Add bpf_arena_map_kern_vm_start() and bpf_prog_arena() Tejun Heo
2026-05-22 17:22 ` [PATCH 6/8] sched_ext: Require an arena for cid-form schedulers Tejun Heo
2026-05-22 17:22 ` [PATCH 7/8] sched_ext: Sub-allocator over kernel-claimed BPF arena pages Tejun Heo
2026-05-22 17:22 ` [PATCH 8/8] sched_ext: Convert ops.set_cmask() to arena-resident cmask Tejun Heo
2026-05-25 15:45 ` [PATCHSET v4 sched_ext/for-7.2] bpf/arena: Direct kernel-side access Alexei Starovoitov
2026-05-25 19:54 ` Tejun Heo
  -- strict thread matches above, loose matches on Subject: below --
2026-05-20 23:50 [PATCHSET v3 " Tejun Heo
2026-05-20 23:50 ` [PATCH 2/8] bpf: Recover arena kernel faults with scratch page Tejun Heo
2026-05-21  3:16   ` Emil Tsalapatis
2026-05-21  9:42   ` Alexei Starovoitov
2026-05-21 17:39     ` Tejun Heo
2026-05-17 21:12 [PATCHSET v2 sched_ext/for-7.2] bpf/arena: Direct kernel-side access Tejun Heo
2026-05-17 21:12 ` [PATCH 2/8] bpf: Recover arena kernel faults with scratch page Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DIUMP21RASZI.2VNQV45RIL209@gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrii@kernel.org \
    --cc=arighi@nvidia.com \
    --cc=ast@kernel.org \
    --cc=bp@alien8.de \
    --cc=bpf@vger.kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=changwoo@igalia.com \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@kernel.org \
    --cc=emil@etsalapatis.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rppt@kernel.org \
    --cc=sched-ext@lists.linux.dev \
    --cc=tglx@kernel.org \
    --cc=tj@kernel.org \
    --cc=void@manifault.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.