Re: [PATCH] dax: Fix ENOMEM handling in grab_mapping_entry()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jan,

I was out for a few days...

On Tue, Jun 22, 2021 at 9:00 AM Jan Kara <jack@xxxxxxx> wrote:
>
> 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 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.
>
> Fixes: b15cd800682f ("dax: Convert page fault handlers to XArray")
> Signed-off-by: Jan Kara <jack@xxxxxxx>

Looks good to me:

Reviewed-by: Dan Williams <dan.j.williams@xxxxxxxxx>

I notice that Andrew already picked this up and I'm ok to let it
percolate up to Linus through -mm.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux