Messages in this thread | | | Date | Wed, 23 Nov 2022 09:40:03 +0100 | Subject | Re: [PATCH v1] mm/gup: disallow FOLL_FORCE|FOLL_WRITE on hugetlb mappings | From | David Hildenbrand <> |
| |
On 23.11.22 00:48, Mike Kravetz wrote: > On 11/22/22 15:03, Andrew Morton wrote: >> On Tue, 22 Nov 2022 13:59:25 -0400 Jason Gunthorpe <jgg@nvidia.com> wrote: >> >>>>> >>>>> While that's certainly valid, it's not the common use case with >>>>> hugetlb pages. >>>> >>>> FWIW, I did check with our product teams and they do not knowingly make use >>>> of private mappings without write. Of course, that is only a small and >>>> limited sample size. >>> >>> Yeah, if it is only this case I'm comfortable as well >>> >> >> So.... I am to slap a cc:stable on this patch and we're all good? > > I think we will also need a Fixes tag. There are two options for this: > 1) In this patch David rightly points out > "I assume this has been broken at least since 2014, when mm/gup.c came to > life. I failed to come up with a suitable Fixes tag quickly." > So, we could go with some old gup commit. > 2) One of the benefits of this patch is silencing the warning introduced > by 1d8d14641fd9 ("mm/hugetlb: support write-faults in shared mappings"). > So, we could use this for the tag. It is also more in line with David's > suggestion to "backport it into 6.0/6.1 to fix the warning". > > My suggestion would be to use 1d8d14641fd9 for the fixes tag. However, > David may have a better suggestion/idea.
Right, in an ideal world we'd backport this patch here to the dawn of time where hugetlb + gup came to life and FOLL_FORCE was not properly fenced of for hugetlb.
However, such a patch is not really stable-worthy I guess. So I'm fine with "fixing the warning introduced for finding such previously wrong behavior" instead.
Fixes: 1d8d14641fd9 ("mm/hugetlb: support write-faults in shared mappings") Cc: <stable@vger.kernel.org>
-- Thanks,
David / dhildenb
| |