linux-kernel - Re: [PATCH v1] mm/gup: disallow FOLL_FORCE|FOLL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <eeef7d42-4e89-eafc-ab0f-e65de3a2cccc@redhat.com>
Date:   Wed, 23 Nov 2022 09:40:03 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Jason Gunthorpe <jgg@...dia.com>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Peter Xu <peterx@...hat.com>,
        John Hubbard <jhubbard@...dia.com>,
        syzbot+f0b97304ef90f0d0b1dc@...kaller.appspotmail.com
Subject: Re: [PATCH v1] mm/gup: disallow FOLL_FORCE|FOLL_WRITE on hugetlb
 mappings

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@...dia.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@...r.kernel.org>

-- 
Thanks,

David / dhildenb