lkml.org 
[lkml]   [2020]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 2/2] mm: prevent gup_fast from racing with COW during fork
On Fri 30-10-20 14:02:26, Jason Gunthorpe wrote:
> On Fri, Oct 30, 2020 at 05:51:05PM +0100, Jan Kara wrote:
> > > @@ -446,6 +447,12 @@ struct mm_struct {
> > > */
> > > atomic_t has_pinned;
> > >
> > > + /**
> > > + * @write_protect_seq: Odd when any thread is write protecting
> > > + * pages in this mm, for instance during fork().
> > > + */
> > > + seqcount_t write_protect_seq;
> > > +
> >
> > So this comment isn't quite true. We can be writeprotecting pages due to
> > many other reasons and not touch write_protect_seq. E.g. for shared
> > mappings or due to explicit mprotect() calls. So the write_protect_seq
> > protection has to be about something more than pure write protection. One
> > requirement certainly is that the VMA has to be is_cow_mapping(). What
> > about mprotect(2) calls? I guess the application would have only itself to
> > blame so we don't care?
>
> Yes, that sounds right, How about
>
> /**
> * @write_protect_seq: Locked when any thread is write protecting
> * pages for COW in this mm, for instance during page table copying
^^^ maybe I'd write a bit more explicitly "... write protecting
pages mapped by this mm to enforce later COW, ..."

> * for fork().
> */
>
> mprotect and shared mappings cause faults on write access not COW?

Correct.

Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR

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