dax: fix ENOMEM handling in grab_mapping_entry()
grab_mapping_entry() has a bug in handling of ENOMEM condition. Suppose
we have a PMD entry at index i which we are downgrading to a PTE entry.
grab_mapping_entry() will set pmd_downgrade to true, lock the entry, clear
the entry in xarray, and decrement mapping->nrpages. The it will call:
entry = dax_make_entry(pfn_to_pfn_t(0), flags);
dax_lock_entry(xas, entry);
which inserts new PTE entry into xarray. However this may fail allocating
the new node. We handle this by:
if (xas_nomem(xas, mapping_gfp_mask(mapping) & ~__GFP_HIGHMEM))
goto retry;
however pmd_downgrade stays set to true even though 'entry' returned from
get_unlocked_entry() will be NULL now. And we will go again through the
downgrade branch. This is mostly harmless except that mapping->nrpages is
decremented again and we temporarily have an invalid entry stored in
xarray. Fix the problem by setting pmd_downgrade to false each time we
lookup the entry we work with so that it matches the entry we found.
Link: https://lkml.kernel.org/r/20210622160015.18004-1-jack@suse.cz
Fixes: b15cd80068
("dax: Convert page fault handlers to XArray")
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
parent
54dd200c5a
commit
1a14e3779d
3
fs/dax.c
3
fs/dax.c
@ -488,10 +488,11 @@ static void *grab_mapping_entry(struct xa_state *xas,
|
||||
struct address_space *mapping, unsigned int order)
|
||||
{
|
||||
unsigned long index = xas->xa_index;
|
||||
bool pmd_downgrade = false; /* splitting PMD entry into PTE entries? */
|
||||
bool pmd_downgrade; /* splitting PMD entry into PTE entries? */
|
||||
void *entry;
|
||||
|
||||
retry:
|
||||
pmd_downgrade = false;
|
||||
xas_lock_irq(xas);
|
||||
entry = get_unlocked_entry(xas, order);
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user