+++ Peter Zijlstra [14/07/17 18:10 +0200]:
On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote:
On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote:
> Urgh, is for some mysterious reason the __bug_table section of modules
> ending up in RO memory?
>
> I forever get lost in that link magic :/
+1
drm.ko
20 __bug_table 00000630 0000000000000000 0000000000000000 0004bff3 2**0
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
vmlinux
15 __bug_table 0000ba84 ffffffff81af26c0 0000000001af26c0 00cf26c0 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
Danged if I know... um um RELOC business mucks things up?
Argh, it shouldn't be READONLY for vmlinux either, but apparently that
is working for mysterious reasons.
If I'm not mistaken, this works because __bug_table falls outside of
the RO range as specified in the vmlinux linker script (using x86_64
as the example, that means _text - __end_rodata_hpage_align).
mark_rodata_ro() only sets ro memory protections for pages within this
range, so __bug_table remains rw in memory despite its Elf section
flags. Interestingly enough, my .rodata section is set 'WA' (rw) in
vmlinux on my f25 system, so that leads me to think that Elf section
flags in vmlinux don't seem to matter much when it comes to setting
ro/nx protections..
However, in the module loader it's a different story; we do set page
protections strictly according to the section flags, so since
__bug_table only has SHF_ALLOC set, it assumes it's a readonly section
and gets treated as such. So I would think that Josh's patch would fix
this issue.
Jessica
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
