Messages in this thread | | | Date | Tue, 2 Aug 2005 12:54:58 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch 2.6.13-rc4] fix get_user_pages bug |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |