mm/hugetlb: GFP_KERNEL allocation under spinlock?
Hi,
could anybody please confirm this cannot happen?
hugetlb_fault()
-> spin_lock()
-> hugetlb_cow()
-> alloc_huge_page()
-> vma_needs_reservation()
-> region_chg() (either of the 2)
-> kmalloc(*, GFP_KERNEL)Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 2 lines · Jiri Slaby
could anybody please confirm this cannot happen?
I'm no authority on hugetlb.c nowadays: you'll have studied this in more detail than I have, so please don't believe me. (And I'm no longer at my old address, but lkml's enjoying a quiet Sunday.)
Quoted 10 lines
hugetlb_fault()
->spin_lock()
->hugetlb_cow()
->alloc_huge_page()-> vma_needs_reservation() -> region_chg() (either of the 2) -> kmalloc(*, GFP_KERNEL)Thanks.
That should be taken care of by the successful vma_needs_reservation() on the same address in hugetlb_fault(), before taking page_table_lock, shouldn't it?
It is possible that a hugetlb_vmtruncate() comes in between that vma_needs_reservation() and taking the page_table_lock, which could remove the region (or "nrg") needed.
But if that's the case then the pte_same test immediately after taking page_table_lock should catch it: we're in the part of hugetlb_fault() dealing with !huge_pte_none, whereas truncation would have made it huge_pte_none (and it won't get to freeing the reservations before it's nullified the page tables, holding page_table_lock).
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 17 lines · Hugh Dickins
Quoted 2 lines · Jiri Slaby
could anybody please confirm this cannot happen?
I'm no authority on
hugetlb.cnowadays: you'll have studied this in more detail than I have, so please don't believe me. (And I'm no longer at my old address, but lkml's enjoying a quiet Sunday.)Quoted 9 lines
hugetlb_fault()
->spin_lock()
->hugetlb_cow()
->alloc_huge_page()-> vma_needs_reservation() -> region_chg() (either of the 2) -> kmalloc(*, GFP_KERNEL)
Quoted 6 lines
Quoted 1 line
Thanks.
That should be taken care of by the successful
vma_needs_reservation()on the same address inhugetlb_fault(), before takingpage_table_lock, shouldn't it?
Yes, any kmalloc() required should be happening outside spinlocks. The region_chg and region_add acts like a prepare,commit pair except the naming is diabolical. There was a mistake made at one point where kmalloc() was called within a spinlock but enabling lock debugging caught it.
Quoted 10 lines
It is possible that a
hugetlb_vmtruncate()comes in between thatvma_needs_reservation()and taking thepage_table_lock, which could remove the region (or "nrg") needed.But if that's the case then the
pte_sametest immediately after takingpage_table_lockshould catch it: we're in the part ofhugetlb_fault()dealing with !huge_pte_none, whereas truncation would have made ithuge_pte_none(and it won't get to freeing the reservations before it's nullified the page tables, holdingpage_table_lock).
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>