On Tue, Dec 10, 2024 at 5:06 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote: > From: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> > > gup_pgd_range() is invoked with disabled interrupts and invokes There is no gup_pgd_range() in the kernel, is this patch a bit old? There is gup_fast_pgd_range(). See 23babe1934d7637b598e4c9d9f3876e318fa63a4 gup.c contains: get_user_pages_fast attempts to pin user pages by walking the page tables directly and avoids taking locks. (...) Let's consistently call the "fast-only" part of GUP "GUP-fast" and rename all relevant internal functions to start with "gup_fast", to make it clearer that this is not ordinary GUP. The current mixture of "lockless", "gup" and "gup_fast" is confusing. 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? > __kmap_local_page_prot() via pte_offset_map(), gup_p4d_range(). > With HIGHPTE enabled, __kmap_local_page_prot() invokes kmap_high_get() > which uses a spinlock_t via lock_kmap_any(). This leads to an > sleeping-while-atomic error on PREEMPT_RT because spinlock_t becomes a > sleeping lock and must not be acquired in atomic context. I think this needs to be inspected by David Hildenbrand, if he consistently rename the GPU functions to be "fast" and there is a lock somewhere deep in there, something must be wrong and violating the API contract. > The loop in map_new_virtual() uses wait_queue_head_t for wake up which > also is using a spinlock_t. > > Since HIGHPTE is rarely needed at all, turn it off for PREEMPT_RT > to allow the use of get_user_pages_fast(). > > [arnd: rework patch to turn off HIGHPTE instead of HAVE_PAST_GUP] HAVE_FAST_GUP I'm still confused, how can something that is supposed to be lockless "fast" acquire a spinlock? Something is odd here. > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> > --- > There is an open question about whether HIGHPTE is still needed > at all, given how rare 32-bit machines with more than 4GB > are on any architecture. If we instead decide to remove HIGHPTE > altogether, this patch is no longer needed. 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. Yours, Linus Walleij
