On 11.08.22 01:55, Mike Kravetz wrote:
> On 08/10/22 15:52, Peter Xu wrote:
>> On Wed, Aug 10, 2022 at 09:40:11PM +0200, David Hildenbrand wrote:
>>> On 10.08.22 21:29, Peter Xu wrote:
>>>> On Wed, Aug 10, 2022 at 11:37:13AM +0200, David Hildenbrand wrote:
>>>>> On 09.08.22 00:08, Peter Xu wrote:
>>>>>> On Mon, Aug 08, 2022 at 04:21:39PM -0400, Peter Xu wrote:
>>>>>>> On Mon, Aug 08, 2022 at 06:25:21PM +0200, David Hildenbrand wrote:
>>>>>>>>>> Relying on VM_SHARED to detect MAP_PRIVATE vs. MAP_SHARED is
>>>>>>>>>> unfortunately wrong.
>>>>>>>>>>
>>>>>>>>>> If you're curious, take a look at f83a275dbc5c ("mm: account for
>>>>>>>>>> MAP_SHARED mappings using VM_MAYSHARE and not VM_SHARED in hugetlbfs")
>>>>>>>>>> and mmap() code.
>>>>>>>>>>
>>>>>>>>>> Long story short: if the file is read-only, we only have VM_MAYSHARE but
>>>>>>>>>> not VM_SHARED (and consequently also not VM_MAYWRITE).
>>>>>>>>>
>>>>>>>>> To ask in another way: if file is RO but mapped RW (mmap() will have
>>>>>>>>> VM_SHARED cleared but VM_MAYSHARE set), then if we check VM_MAYSHARE here
>>>>>>>>> won't we grant write bit errornously while we shouldn't? As the user
>>>>>>>>> doesn't really have write permission to the file.
>>>>>>>>
>>>>>>>> Thus the VM_WRITE check. :)
>>>>>>>>
>>>>>>>> I wonder if we should just do it cleanly and introduce the maybe_mkwrite
>>>>>>>> semantics here as well. Then there is no need for additional VM_WRITE
>>>>>>>> checks and hugetlb will work just like !hugetlb.
>>>>>>>
>>>>>>> Hmm yeah I think the VM_MAYSHARE check is correct, since we'll need to fail
>>>>>>> the cases where MAYSHARE && !SHARE - we used to silently let it pass.
>>>>>>
>>>>>> Sorry I think this is a wrong statement I made.. IIUC we'll fail correctly
>>>>>> with/without the patch on any write to hugetlb RO regions.
>>>>>>
>>>>>> Then I just don't see a difference on checking VM_SHARED or VM_MAYSHARE
>>>>>> here, it's just that VM_MAYSHARE check should work too like VM_SHARED so I
>>>>>> don't see a problem.
>>>>>>
>>>>>> It also means I can't think of any valid case of having VM_WRITE when
>>>>>> reaching here, then the WARN_ON_ONCE() is okay but maybe also redundant.
>>>>>> Using maybe_mkwrite() seems misleading to me if FOLL_FORCE not ready for
>>>>>> hugetlbfs after all.
>>>>>>
>>>>>
>>>>> The main reason we'd have it would be to scream out lout and fail
>>>>> gracefully if someone would -- for example -- use it for something like
>>>>> FOLL_FORCE.
>>>>
>>>> Having that WARN_ON_ONCE() is okay to me, but just to double check we're on
>>>> the same page: why there's concern on using FOLL_FORCE? IIUC we're talking
>>>> about shared mappings here, then no FOLL_FORCE possible at all? IOW,
>>>> "!is_cow_mapping()" should fail in check_vma_flags() already.
>>>
>>> This code path also covers the anon case.
>>
>> But this specific warning is under the VM_MAYSHARE if clause just added in
>> this patch?
>>
>> My understanding is any FOLL_FORCE will always constantly fail before this
>> patch, and it should keep failing as usual and I don't see any case it'll
>> be failing at the warn_on_once here.
>>
>> So again, I'm fine with having the warning, but I just want to make sure
>> what you want to capture is what you expected..
>>
>>>>
>>>> The other thing is I'm wondering whether patch 2 should be postponed anyway
>>>> so that we can wait for a full resolution of the problem from Mike.
>>>
>>> To make the code more robust and avoid any other such surprises I prefer
>>> to have this in rather earlier than later.
>>>
>>> As the commit says "Let's add a safety net ..."
>>
>> Sure, no strong opinion. I'll leave that to Mike. Thanks,
>>
>
> Sorry that I am not contributing to this thread more. Need to spend
> some time educating myself on the relatively new semantics here.
>
> As mentioned, softdirty is on my todo list but has been there for over a
> year. So, better to add a safety net until that code moves forward.
>
> However, just for clarification. The only way we KNOW of to encounter
> these situations today via softdirty. Patch 1 takes care of that. This
> patch catches any unknown ways we may get here. Correct? i.e. We don't
> really expect to exercise these code paths.
While I do love a good challenge on a Thursday morning, I wish I could
spend less time writing reproducers and arguing about obviously shaky
code ;) . Having that said, there is a flaw in uffd-wp that will end up
in the same code path and similarly mess up.
I'll resend including the reproducer. Note that I'll be on vacation for
~ 1.5 weeks.
--
Thanks,
David / dhildenb
