On 2021/8/17 15:29, HORIGUCHI NAOYA(堀口 直也) wrote:

On Sat, Aug 14, 2021 at 06:51:29PM +0800, Miaohe Lin wrote:

quoted

If the first pte is equal to poisoned_pfn, i.e. check_hwpoisoned_entry()
return 1, the wrong ptep - 1 would be passed to pte_unmap_unlock().

Fixes: ad9c59c24095 ("mm,hwpoison: send SIGBUS with error virutal address")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>

I agree with the change itself, so

Acked-by: Naoya Horiguchi <redacted>

Many thanks for your review and Acked-by tag!

One question is that according to "grep -r pte_unmap_unlock ." command over
whole kernel source code, pte_unmap_unlock() is called with "ptep - 1" in some places.
I think that none of them seems to have "break in for loop" in locked period,
so the same problem does not occur there.  But I'm still not sure why some place
call with "ptep - 1" and the others call with pte returned by pte_offset_map_lock().

IMO pte_unmap_unlock() works as long as the passed in pte belongs to the same page returned
from pte_offset_map_lock(). I have fixed some similar place where pte_unmap_unlock() is called
with wrong "ptep - 1" when I was learning the related mm code.