Message ID | 20220704013312.2415700-3-naoya.horiguchi@linux.dev (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | mm, hwpoison: enable 1GB hugepage support (v4) | expand |
On Mon, 4 Jul 2022 10:33:05 +0900 Naoya Horiguchi <naoya.horiguchi@linux.dev> wrote: > Originally copy_hugetlb_page_range() handles migration entries and hwpoisoned > entries in similar manner. But recently the related code path has more code > for migration entries, and when is_writable_migration_entry() was converted > to !is_readable_migration_entry(), hwpoison entries on source processes got > to be unexpectedly updated (which is legitimate for migration entries, but > not for hwpoison entries). This results in unexpected serious issues like > kernel panic when forking processes with hwpoison entries in pmd. > > Separate the if branch into one for hwpoison entries and one for migration > entries. > > ... > > Cc: <stable@vger.kernel.org> # 5.18 It's unusual to have a cc:stable patch in the middle of a series like this. One would expect the fix to be a standalone thing against current -linus. As presented, this patch won't get into mainline until after 5.20-rc1. If that's OK then OK. Otherwise I can shuffle things around and stage this patch in mm-hotfixes?
On Sun, Jul 03, 2022 at 06:42:59PM -0700, Andrew Morton wrote: > On Mon, 4 Jul 2022 10:33:05 +0900 Naoya Horiguchi <naoya.horiguchi@linux.dev> wrote: > > > Originally copy_hugetlb_page_range() handles migration entries and hwpoisoned > > entries in similar manner. But recently the related code path has more code > > for migration entries, and when is_writable_migration_entry() was converted > > to !is_readable_migration_entry(), hwpoison entries on source processes got > > to be unexpectedly updated (which is legitimate for migration entries, but > > not for hwpoison entries). This results in unexpected serious issues like > > kernel panic when forking processes with hwpoison entries in pmd. > > > > Separate the if branch into one for hwpoison entries and one for migration > > entries. > > > > ... > > > > Cc: <stable@vger.kernel.org> # 5.18 > > It's unusual to have a cc:stable patch in the middle of a series like > this. One would expect the fix to be a standalone thing against > current -linus. Ah, OK, I should've submit this seperately. > > As presented, this patch won't get into mainline until after 5.20-rc1. > If that's OK then OK. Otherwise I can shuffle things around and stage > this patch in mm-hotfixes? Yes, I'd like to ask you to do it. Thank you for the arrangement. - Naoya Horiguchi
diff --git a/mm/hugetlb.c b/mm/hugetlb.c index bdc4499f324b..ad621688370b 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4803,8 +4803,13 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, * sharing with another vma. */ ; - } else if (unlikely(is_hugetlb_entry_migration(entry) || - is_hugetlb_entry_hwpoisoned(entry))) { + } else if (unlikely(is_hugetlb_entry_hwpoisoned(entry))) { + bool uffd_wp = huge_pte_uffd_wp(entry); + + if (!userfaultfd_wp(dst_vma) && uffd_wp) + entry = huge_pte_clear_uffd_wp(entry); + set_huge_pte_at(dst, addr, dst_pte, entry); + } else if (unlikely(is_hugetlb_entry_migration(entry))) { swp_entry_t swp_entry = pte_to_swp_entry(entry); bool uffd_wp = huge_pte_uffd_wp(entry);