• Dan Williams's avatar
    device-dax: switch to srcu, fix rcu_read_lock() vs pte allocation · 956a4cd2
    Dan Williams authored
    The following warning triggers with a new unit test that stresses the
    device-dax interface.
    
     ===============================
     [ ERR: suspicious RCU usage.  ]
     4.11.0-rc4+ #1049 Tainted: G           O
     -------------------------------
     ./include/linux/rcupdate.h:521 Illegal context switch in RCU read-side critical section!
    
     other info that might help us debug this:
    
     rcu_scheduler_active = 2, debug_locks = 0
     2 locks held by fio/9070:
      #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8d0739d7>] __do_page_fault+0x167/0x4f0
      #1:  (rcu_read_lock){......}, at: [<ffffffffc03fbd02>] dax_dev_huge_fault+0x32/0x620 [dax]
    
     Call Trace:
      dump_stack+0x86/0xc3
      lockdep_rcu_suspicious+0xd7/0x110
      ___might_sleep+0xac/0x250
      __might_sleep+0x4a/0x80
      __alloc_pages_nodemask+0x23a/0x360
      alloc_pages_current+0xa1/0x1f0
      pte_alloc_one+0x17/0x80
      __pte_alloc+0x1e/0x120
      __get_locked_pte+0x1bf/0x1d0
      insert_pfn.isra.70+0x3a/0x100
      ? lookup_memtype+0xa6/0xd0
      vm_insert_mixed+0x64/0x90
      dax_dev_huge_fault+0x520/0x620 [dax]
      ? dax_dev_huge_fault+0x32/0x620 [dax]
      dax_dev_fault+0x10/0x20 [dax]
      __do_fault+0x1e/0x140
      __handle_mm_fault+0x9af/0x10d0
      handle_mm_fault+0x16d/0x370
      ? handle_mm_fault+0x47/0x370
      __do_page_fault+0x28c/0x4f0
      trace_do_page_fault+0x58/0x2a0
      do_async_page_fault+0x1a/0xa0
      async_page_fault+0x28/0x30
    
    Inserting a page table entry may trigger an allocation while we are
    holding a read lock to keep the device instance alive for the duration
    of the fault. Use srcu for this keep-alive protection.
    
    Fixes: dee41079 ("/dev/dax, core: file operations and dax-mmap")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    956a4cd2
dax.c 20.5 KB