fixup_user_fault(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ fixup_user_fault(9) ✨

okay so real talk, this is a page from the Kernel API Manual and it's all about fixup_user_fault β€” manually resolving a user page fault. bestie, let's get into it πŸ’…


🌸 SYNOPSIS 🌸

int fixup_user_fault (struct mm_struct *mm , unsigned long address ,
       unsigned int fault_flags , bool *unlocked );

πŸŽ€ ARGUMENTS πŸŽ€

  • mm β€” the mm_struct of the target mm. that's the memory map you're working with, periodt.
  • address β€” the user address. yep, that one.
  • fault_flags β€” flags to pass down to handle_mm_fault. literally handing them off, no notes.
  • unlocked β€” did we unlock the mmap_lock while retrying? it can maybe be NULL if the caller does not allow retry. ⚠️ and if it is NULL, the caller must guarantee that fault_flags does not contain FAULT_FLAG_ALLOW_RETRY. no cap, that's a hard requirement.

πŸ¦‹ DESCRIPTION πŸ¦‹

so this is meant to be called in the very specific scenario where, for locking reasons, we try to access user memory in atomic context (within a pagefault_disable section), it returns -EFAULT, and we want to resolve the user fault before trying again. it's giving "let me fix this before we go back in" energy 😭✨

typically this is meant to be used by the futex code. iykyk.

the main difference with get_user_pages is that this function will unconditionally call handle_mm_fault, which will in turn perform all the necessary SW fixup of the dirty and young bits in the PTE β€” whereas get_user_pages only guarantees to update these in the struct page. okay so that's a whole thing. πŸ”₯

this is important for some architectures where those bits also gate the access permission to the page, because they are maintained in software. on such architectures, gup will not be enough to make a subsequent access succeed. fr fr, it just won't. πŸ’€

this function will not return with an unlocked mmap_lock. so it has not the same semantics wrt the mm->mmap_lock as does filemap_fault. keep that in mind bestie, they are not the same vibe.

πŸ’œ SEE ALSO πŸ’œ

the Kernel file ./mm/gup.c says hi πŸ‘‹ β€” go check out:

try_grab_folio(9), unpin_user_page(9), unpin_folio(9), folio_add_pin(9), unpin_user_pages_dirty_lock(9), unpin_user_page_range_dirty_lock(9), unpin_user_pages(9), unpin_user_folio(9), unpin_folios(9), try_grab_folio_fast(9), follow_page_mask(9), __get_user_pages(9), populate_vma_page_range(9), fault_in_writeable(9), fault_in_subpage_writeable(9), fault_in_readable(9), get_dump_page(9), get_user_pages_remote(9), get_user_pages(9), get_user_pages_fast_only(9), get_user_pages_fast(9), pin_user_pages_fast(9), pin_user_pages_remote(9), pin_user_pages(9), memfd_pin_folios(9), folio_add_pins(9) β€” that's the whole squad, go say hi 🫢


and that's the page!! πŸŽ€ this lil gem lives in ./mm and it's dated October 2026 β€” slay, iconic, no notes, bye bestie πŸ’–βœ¨

πŸ“¦ where this page comes from