Looking at both the i386 and x86-64 implementations I fail to understand why there is an explicit requirement on calling global_flush_tlb() after change_page_attr(), yet actual TLB flushing will not normally happen (on i386 it will happen if the CPU doesn't support clflush, but if it does, or on x86-64, the flushing depends on the list of deferred pages being non-empty, which can only happen when a large page gets re-combined). Is it assumed that the callers additionally call tlb_flush_all() (I think none of them do)?
Further, change_page_attr()'s reference counting in a split large page's page table appears to imply that attributes are only changed from or back to the reference attributes, but not from one kind of non-default ones to the same or another set of non-default ones (otherwise the reference count will never again drop to zero), and also not from default to default (i.e. the caller trying to revert attributes to normal not knowing what state they are currently in) - this would BUG() if the large page was already reverted, or screw the reference count otherwise. Is all of this intentional? I think it will need to be changed as a prerequisite to supporting on-the-fly attribute changes in the SMP alternatives code, which was requested as a follow-up to the tightening of the CONFIG_DEBUG_RODATA effects. Finally, at least for the kernel image range it would seem to me that it might be beneficial to recombine mappings into large ones even when the attributes are not at their default anymore, but consistent across an entire 2Mb/4Mb range (i.e. after write-protecting .text). At the same time I wonder, though, whether it wouldn't be safer to remove execute permission from anything but .text along with write-protecting read-only regions under CONFIG_DEBUG_RODATA. Thanks for any insight, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/