On Fri, Dec 13, 2024 at 09:11:57AM +0000, Russell King (Oracle) wrote: > On Fri, Dec 13, 2024 at 01:27:00AM +0100, Linus Walleij wrote: > > On Wed, Dec 11, 2024 at 4:22 PM Sebastian Andrzej Siewior > > <bigeasy@xxxxxxxxxxxxx> wrote: > > > On 2024-12-11 14:29:29 [+0100], Linus Walleij wrote: > > > > So fast GUP is supposed to be lockless, and should just not > > > > have this problem. So it can't be addressing gup_fast_pgd_range() > > > > right? > > > … > > > > I'm more asking if HIGHPTE even acquires a spinlock anymore > > > > as it is supposed to be "fast"/lockless. If it does, it is clearly violating > > > > the "fast" promise of the fast GUP API and should not exist. > > > > > > This is lockless on x86. The problem is ARM's > > > arch_kmap_local_high_get(). This is where the lock is from. > > > > Aha that calls down to kmap_high_get() that that issues > > lock_kmap_any(flags). > > > > But is it really sound that the "fast" API does this? It feels > > like a violation of the whole design of the fast stuff. > > If there's no way to do it lockless, then it has to take the lock. Well, no, it's allowed to fail. It could trylock and fail if it can't get the lock.
