Re: [PATCH] fs/dax: Remove redundant deferred list initialization

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] dax_delete_mapping_range() splits PMD entries and causes duplicate processing leading to nrpages underflow
--

commit ab9d688e10fd86aba4bb8d5161b095d144b422c0
Author: Kaitao Cheng <chengkaitao@kylinos.cn>

fs/dax: Remove redundant deferred list initialization

This commit removes the redundant initialization of folio->_deferred_list
for large DAX folios in dax_folio_init(). This is because prep_compound_head()
already handles it, leaving compound folio initialization centralized.

> diff --git a/fs/dax.c b/fs/dax.c
> index 1fbba0d21c13d..4ea0f13d53a65 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
[ ... ]

[Severity: Critical]
This isn't a bug introduced by this patch, but I noticed a potential
pre-existing issue in dax_delete_mapping_range() when it processes
multi-order DAX entries:

fs/dax.c:dax_delete_mapping_range() {
    ...
    XA_STATE(xas, &mapping->i_pages, start_idx);
    ...
    xas_for_each(&xas, entry, end_idx) {
        if (!xa_is_value(entry))
            continue;
        entry = wait_entry_unlocked_exclusive(&xas, entry);
        if (!entry)
            continue;
        dax_disassociate_entry(entry, mapping, true);
        xas_store(&xas, NULL);
        mapping->nrpages -= 1UL << dax_entry_order(entry);
        put_unlocked_entry(&xas, entry, WAKE_ALL);
    }
    ...
}

When deleting a mapping range on a DAX filesystem containing PMD-sized
entries, this loop uses an order-0 XA_STATE. If xas_store() encounters an
order-9 PMD entry, doesn't it split the entry into 512 order-0 entries
(one NULL and 511 copies of the PMD value)?

Because xas_advance() is not called after the store, will the iterator
continue to visit the remaining 511 split sibling slots and process the same
PMD entry again?

Since mapping->nrpages is decremented by 1UL << dax_entry_order(entry) (which
is 512 for a PMD entry) on each iteration, could this underflow the counter by
262,144 per PMD entry and result in catastrophic memory accounting corruption?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903050207.7015-1-kaitao.cheng@linux.dev?part=1