Re: [PATCH 1/8] mm: Add ptep_try_install() for lockless empty-slot installs

[Tejun Heo <tj@kernel.org>]

On Tue, May 19, 2026 at 11:40:48AM +0200, David Hildenbrand (Arm) wrote:
> On 5/19/26 11:05, David Hildenbrand (Arm) wrote:
...
> >> The only requirements are that the kernel doesn't oops and the
> >> violation gets caught. Beyond that, behavior at the address is
> >> unspecified, and which installer wins the race doesn't matter as
> >> long as kernel integrity holds.
> > 
> > You'll have inconsistent TLB state.

Wouldn't it still be either or with both cases being okay?

> > I really don't like that approach.
> > 
> > We should really try to just take the lock, and remove any code under the lock
> > that could trigger such unpleasant deadlocks.
> > 
> > Is that feasible?
> 
> ... or can we run into similar problems with kprobes? (I am obviously no bpf
> expert ...)

Yeah, I mean, that was just the first TP I found scanning the code. Any
kprobes or other TPs in the path would behave the same.

When this fault triggers, the BPF program has already malfunctioned, so it's
not going to be a high frequency path and performance isn't a primary
consideration. So, anything that can ensure that the kernel doesn't crash or
lock up would be fine. Any better ideas?

Thanks.

-- 
tejun