Re: FAILED: patch "[PATCH] mm/hugetlb: take page table lock in follow_huge_pmd()" failed to apply to 3.19-stable tree

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

 



On Mon, Mar 16, 2015 at 11:08:54AM +0100, Jiri Slaby wrote:
> On 03/16/2015, 10:06 AM, Naoya Horiguchi wrote:
> > On Wed, Mar 11, 2015 at 02:35:10PM +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
> >> ------------------ original commit in Linus's tree ------------------
> >>
> >> From e66f17ff71772b209eed39de35aaa99ba819c93d Mon Sep 17 00:00:00 2001
> >> From: Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx>
> >> Date: Wed, 11 Feb 2015 15:25:22 -0800
> >> Subject: [PATCH] mm/hugetlb: take page table lock in follow_huge_pmd()
> > 
> > This patch depends on commit 61f77eda9bbf ("mm/hugetlb: reduce arch
> > dependent code around follow_huge_*"), so we need backport this with it.
> > Unfortunately, 61f77eda9bbf doesn't apply cleanly on v3.19.1 because of
> > commit 25153a83b04f ("mm/hugetlb: take page table lock in follow_huge_pmd()"),
> > which is already merged at v3.19.1 separately.
> 
> Hi,
> 
> I am confused as my e66f17ff7177 is "mm/hugetlb: take page table lock in
> follow_huge_pmd()". But you refer to this commit as (non-existing)
> 25153a83b04f.

Ah sorry for the confusion, 25153a83b04f was the ID in my local tree to
test backporting.

> Currently, I have this in 3.12 (git log order):
> e66f17ff7177 mm/hugetlb: take page table lock in follow_huge_pmd()
> 61f77eda9bbf mm/hugetlb: reduce arch dependent code around follow_huge_*
> 9ab3b598d2df mm: hwpoison: drop lru_add_drain_all() in __soft_offline_page()
> 
> Could you clarify what else do I need, if anything?

There're 3 other related fixes merged in 4.0-rc1 (git-log order):
9fbc1f635fd0 ("mm/hugetlb: add migration entry check in __unmap_hugepage_range")
a8bda28d87c3 ("mm/hugetlb: add migration/hwpoisoned entry check in hugetlb_change_protection")
0f792cf949a0 ("mm/hugetlb: fix getting refcount 0 page in hugetlb_fault()")

I think that the first 2 are easy to apply, but 0f792cf949a0 isn't.
0f792cf949a0 depends on core changes on page table lock after 3.12, so I don't
think the resolve is trivial, so we had better skip it.
Fortunately, these 3 patches are independent of each other, so applying the first
2 patches does work.

Thanks,
Naoya Horiguchi--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]