[PATCH 08/11] x86/mm: do not forbid _PAGE_RW before init for __ro_after_init

From: Dave Hansen __ro_after_init data gets stuck in the .rodata section. That's normally fine because the kernel itself manages the R/W properties. But, if we run __change_page_attr() on an area which is __ro_after_init, the .rodata checks will trigger and force the area to be immediately rea

[PATCH 08/11] x86/mm: do not forbid _PAGE_RW before init for __ro_after_init

From: Dave Hansen __ro_after_init data gets stuck in the .rodata section. That's normally fine because the kernel itself manages the R/W properties. But, if we run __change_page_attr() on an area which is __ro_after_init, the .rodata checks will trigger and force the area to be immediately rea

[PATCH 08/11] x86/mm: do not forbid _PAGE_RW before init for __ro_after_init

From: Dave Hansen __ro_after_init data gets stuck in the .rodata section. That's normally fine because the kernel itself manages the R/W properties. But, if we run __change_page_attr() on an area which is __ro_after_init, the .rodata checks will trigger and force the area to be immediately rea

[PATCH 08/11] x86/mm: do not forbid _PAGE_RW before init for __ro_after_init

From: Dave Hansen __ro_after_init data gets stuck in the .rodata section. That's normally fine because the kernel itself manages the R/W properties. But, if we run __change_page_attr() on an area which is __ro_after_init, the .rodata checks will trigger and force the area to be immediately rea