Nouveau - Jul 2017 - [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

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.

Some architectures were in fact complaining that I broke that, and hence
patch:

b5effd3815cc ("debug: Fix __bug_table[] in arch linker scripts")

I think we need professional help with this linking stuff, but who to
ask?

On Fri, 2017-07-14 at 18:10 +0200, Peter Zijlstra wrote:
> 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.
> 
> Some architectures were in fact complaining that I broke that, and hence
> patch:
> 
> b5effd3815cc ("debug: Fix __bug_table[] in arch linker scripts")
> 
> I think we need professional help with this linking stuff, but who to
> ask?
Andy Lutomirski?

On Fri, Jul 14, 2017 at 06:33:01PM +0200, Mike Galbraith
wrote:
> On Fri, 2017-07-14 at 18:10 +0200, Peter Zijlstra wrote:
> > 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.
> > 
> > Some architectures were in fact complaining that I broke that, and
hence
> > patch:
> > 
> > b5effd3815cc ("debug: Fix __bug_table[] in arch linker
scripts")
> > 
> > I think we need professional help with this linking stuff, but who to
> > ask?
> 
> Andy Lutomirski?
Does this fix it?


diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 39e702d..aa6b202 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -35,7 +35,7 @@
 #define _BUG_FLAGS(ins, flags)						\
 do {									\
 	asm volatile("1:\t" ins "\n"					\
-		     ".pushsection __bug_table,\"a\"\n"			\
+		     ".pushsection __bug_table,\"aw\"\n"		\
 		     "2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n"	\
 		     "\t"  __BUG_REL(%c0) "\t# bug_entry::file\n"	\
 		     "\t.word %c1"        "\t# bug_entry::line\n"	\
@@ -52,7 +52,7 @@ do {									\
 #define _BUG_FLAGS(ins, flags)						\
 do {									\
 	asm volatile("1:\t" ins "\n"					\
-		     ".pushsection __bug_table,\"a\"\n"			\
+		     ".pushsection __bug_table,\"aw\"\n"		\
 		     "2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n"	\
 		     "\t.word %c0"        "\t# bug_entry::flags\n"	\
 		     "\t.org 2b+%c1\n"					\

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