Re: suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Jessica Yu]

+++ 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