The user-space app doesn't even _know_ about dirty bits.
I don't think there's even the possibility of losing dirty bits with
mprotect(), so long as pte_modify doesn't clear the dirty bit, which it
doesn't, in this code:
/* mprotect.c */
entry = ptep_get_and_clear(pte);
set_pte(pte, pte_modify(entry, newprot));
I.e. the only code with the race condition is code which explicitly
clears the dirty bit, in vmscan.c.
Do you see any possibility of losing a dirty bit here?
If not, there's no need for the intricate "gather" or "double scan"
schemes for mprotect() and it can stay as fast as possible.
Btw, a possible mprotect optimisation: there is no need for
flush_tlb_range() when increasing permissions.
-- Jamie
-
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/