On Fri, Oct 30, 2020 at 05:51:05PM +0100, Jan Kara wrote:
> Looks good to me. Just one nit below. With that fixed feel free to add:
>
> Reviewed-by: Jan Kara <jack@xxxxxxx>
Thanks!
> > @@ -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
* for fork().
*/
mprotect and shared mappings cause faults on write access not COW?
Jason
