Re: [PATCH RFC] mm: account VMA before forced-COW via/proc/pid/mem

[Hugh Dickins]

On Sat, 7 Apr 2012, Oleg Nesterov wrote:
> On 04/06, Hugh Dickins wrote:
> >
> > I've long detested that behaviour of GUP write,force, and my strong
> > preference would be not to layer more strangeness upon strangeness,
> > but limit the damage by making GUP write,force fail in that case,
> > instead of inserting a PageAnon page into a VM_SHARED mapping.

Let me reiterate here that I was off at a tangent in bringing this up,
so sorry for any confusion I spread.

> >
> > I think it's unlikely that it will cause a regression in real life
> > (it already fails if you did not open the mmap'ed file for writing),
> 
> Yes, and this is what looks confusing to me. Assuming I understand
> you (and the code) correctly ;)
> 
> If we have a (PROT_READ, MAP_SHARED) file mapping, then FOLL_FORCE
> works depending on "file->f_mode & FMODE_WRITE".
> 
> Afaics, because do_mmap_pgoff(MAP_SHARED) clears VM_MAYWRITE if
> !FMODE_WRITE, and gup(FORCE) checks "vma->vm_flags & VM_MAYWRITE"
> before follow_page/etc.
> 
> OTOH, if the file was opened without FMODE_WRITE, then I do not
> really understand how (PROT_READ, MAP_SHARED) differs from
> (PROT_READ, MAP_PRIVATE).

For normal msyscalls(), !FMODE_WRITE PROT_READ,MAP_SHARED and
PROT_READ,MAP_PRIVATE behave much the same: the difference is that
you can mprotect(PROT_WRITE) the MAP_PRIVATE one, but you cannot
mprotect(PROT_WRITE) the MAP_SHARED - because writes to the latter
would go to the file, and you don't have permission for that.

> However, in the latter case FOLL_FORCE
> works, VM_MAYWRITE was not cleared.

When it comes to __get_user_pages(), FOLL_FORCE allows you to
read from or write to an area to which you don't at present have
read or write access, but could be mprotect()ed to give you that
access (whereas !FOLL_FORCE respects the current mprotection).

So FOLL_FORCE allows reading from any mapped area, even PROT_NONE;
and FOLL_FORCE allows writing to any MAP_PRIVATE area, and writing
to any MAP_SHARED area whose file had been opened with FMODE_WRITE.

The strange weird confusing part is that having checked that you have
permission to write to the file, it then avoids doing so (unless the
area currently has PROT_WRITE): it COWs pages for you instead,
leaving unexpected anon pages in the shared area.

This is believed to be a second line of defence when setting
breakpoints, in case the executable file happened to  have been opened
for writing, to prevent those breakpoints getting back into the file.

> 
> Speaking of the difference above, I'd wish I could understand
> what VM_MAYSHARE actually means except "MAP_SHARED was used".

That's precisely it: so it's very useful in /proc/pid/maps, for
deciding whether to show an 's' or a 'p', but not so often when
real decisions are made (where, as you've observed, private readonly
and shared readonly are treated very similarly, without VM_SHARED).

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/