lkml.org 
[lkml]   [2022]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1 2/2] mm/hugetlb: support write-faults in shared mappings
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.

--
Peter Xu

\
 
 \ /
  Last update: 2022-08-09 00:09    [W:0.080 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site