lkml.org 
[lkml]   [2022]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v1] mm/gup: disallow FOLL_FORCE|FOLL_WRITE on hugetlb mappings
From
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

\
 
 \ /
  Last update: 2022-11-23 09:42    [W:0.117 / U:1.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site