On 2022/8/30 11:57, Dan Williams wrote: > Miaohe Lin wrote: >> On 2022/8/27 1:18, Dan Williams wrote: >>> In the case where a filesystem is polled to take over the memory failure >>> and receives -EOPNOTSUPP it indicates that page->index and page->mapping >>> are valid for reverse mapping the failure address. Introduce >>> FSDAX_INVALID_PGOFF to distinguish when add_to_kill() is being called >>> from mf_dax_kill_procs() by a filesytem vs the typical memory_failure() >>> path. >> >> Thanks for fixing. >> I'm sorry but I can't find the bug report email. > > Report is here: > > https://lore.kernel.org/all/63069db388d43_1b3229426@xxxxxxxxxxxxxxxxxxxxxxxxx.notmuch/ > >> Do you mean mf_dax_kill_procs() can pass an invalid pgoff to the >> add_to_kill()? > > No, the problem is that ->notify_failure() returns -EOPNOTSUPP so > memory_failure_dev_pagemap() falls back to mf_generic_kill_procs(). > However, mf_generic_kill_procs() end up passing '0' for fsdax_pgoff from > collect_procs_file() to add_to_kill(). A '0' for fsdax_pgoff results in > vma_pgoff_address() returning -EFAULT which causes the VM_BUG_ON() in > dev_pagemap_mapping_shift(). Many thanks for your explanation. Reviewed-by: Miaohe Lin <linmiaohe@xxxxxxxxxx> Thanks, Miaohe Lin