Re: [patch 2.6.13-rc4] fix get_user_pages bug

[Linus Torvalds]

On Tue, 2 Aug 2005, Hugh Dickins wrote:
> > 
> > Yes, good point. If the thing is still marked dirty in the TLB, some other 
> > thread might be writing to the page after we've cleared dirty but before 
> > we've flushed the TLB - causing the new dirty bit to be lost. I think.
> 
> Would that matter?  Yes, if vmscan sneaked in at some point while
> page_table_lock is dropped, and wrote away the page with the earlier data.

Right.

> But I was worrying about the reverse case, that we clear dirty, then
> another thread sets it again before we emerge from copy_page_range,
> so it gets left behind granting get_user_pages write permission.

Hmm.. At least x86 won't do that - the dirty bits are updated with an 
atomic read-modify-write sequence that only sets the dirty bit. We won't 
get a writable page somehow.

But the lost dirty bit is nasty.

> I don't believe there's a safe efficient way we could batch clearing
> dirty there. 

Well, there is one really cheap one: look at how many users the VM has.

The thing is, fork() from a threaded environment is simply not done, so we 
could easily have a "slow and careful mode" for the thread case, and 
nobody would probably ever care. 

Whether its worth it, I dunno. It might actually speed up the fork/exit
cases, so it might be worth looking at for that reason.

> I'm thinking of reverting to the old __follow_page, setting write_access
> -1 in the get_user_pages special case (to avoid change to all the arches,
> in some of which write_access is a boolean, in some a bitflag, but in
> none -1), and in that write_access -1 case passing back the special
> code to say do_wp_page has done its full job.  Combining your and
> Nick's and Andrew's ideas, and letting Martin off the hook.
> Or would that disgust you too much?  (We could give -1 a pretty name ;)

Go for it, I think whatever we do won't be wonderfully pretty.

		Linus
-
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/