Messages in this thread | | | Date | Mon, 2 Nov 2020 09:31:22 +0100 | From | Jan Kara <> | Subject | Re: [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
| |