Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1297613 > unrolled thread

Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA Tony Lindgren <tony@atomide.com> - 2015-12-23 21:00 +0100
    Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-12-23 21:10 +0100
      Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA Tony Lindgren <tony@atomide.com> - 2015-12-23 21:20 +0100
    Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA Laura Abbott <labbott@redhat.com> - 2015-12-23 21:40 +0100
      Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA Tony Lindgren <tony@atomide.com> - 2015-12-23 22:30 +0100
        Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA Nicolas Pitre <nicolas.pitre@linaro.org> - 2015-12-23 22:50 +0100
          Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA Tony Lindgren <tony@atomide.com> - 2015-12-24 01:20 +0100
            Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-12-24 01:40 +0100

#1297613 — Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA

* Kees Cook <keescook@chromium.org> [151202 12:31]:
> The use of CONFIG_DEBUG_RODATA is generally seen as an essential part of
> kernel self-protection:
> http://www.openwall.com/lists/kernel-hardening/2015/11/30/13
> Additionally, its name has grown to mean things beyond just rodata. To
> get ARM closer to this, we ought to rearrange the names of the configs
> that control how the kernel protects its memory. What was called
> CONFIG_ARM_KERNMEM_PERMS is really doing the work that other architectures
> call CONFIG_DEBUG_RODATA.
> 
> This redefines CONFIG_DEBUG_RODATA to actually do the bulk of the
> ROing (and NXing). In the place of the old CONFIG_DEBUG_RODATA, use
> CONFIG_DEBUG_ALIGN_RODATA, since that's what the option does: adds
> section alignment for making rodata explicitly NX, as arm does not split
> the page tables like arm64 does without _ALIGN_RODATA.

Also all omap3 boards are now oopsing in Linux next if PM is enabled:

[   18.549865] Unable to handle kernel paging request at virtual address c01237dc
[   18.557830] pgd = cf704000
[   18.560974] [c01237dc] *pgd=8000041e(bad)
[   18.565765] Internal error: Oops: 80d [#1] SMP ARM
[   18.571105] Modules linked in: ledtrig_default_on leds_gpio led_class rtc_twl twl4030_wdt
[   18.581024] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc6-00003-g1bb2057 #2973
[   18.589508] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[   18.596466] task: c0c06638 ti: c0c00000 task.ti: c0c00000
[   18.602539] PC is at wait_dll_lock_timed+0x8/0x14
[   18.607849] LR is at save_context_wfi+0x24/0x28
[   18.612976] pc : [<c0123750>]    lr : [<c01236b0>]    psr: 600e0093
[   18.612976] sp : c0c01ea0  ip : c0c028d4  fp : 00000002
[   18.625549] r10: 00000000  r9 : ffffffff  r8 : 00000000
[   18.631378] r7 : c01237d8  r6 : 00000003  r5 : 0000000a  r4 : 00000001
[   18.638610] r3 : 00000004  r2 : 00000006  r1 : f03fe03a  r0 : 0a000023
[   18.645843] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   18.653839] Control: 10c53879  Table: 8f704019  DAC: 00000051
[   18.660217] Process swapper/0 (pid: 0, stack limit = 0xc0c00218)
[   18.666900] Stack: (0xc0c01ea0 to 0xc0c02000)
[   18.671936] 1ea0: 00000030 c0c01efc 00000003 00000001 00000000 c0c0a0a0 c0c028d4 00000000
[   18.681060] 1ec0: c0122ef8 00000000 c010d210 8f0b0000 c0c01efc 80119dc0 00000000 00000000
[   18.690185] 1ee0: 00000000 00000051 80004019 10c5387d 000000e2 00f00000 00000000 c0c06638
[   18.699279] 1f00: cf6a4e00 00000003 00000001 00000000 c0c0a0a0 00000000 00000000 c010d3bc
[   18.708404] 1f20: c0cbd460 c0cbdd14 00000003 c012308c 00000003 c0c09f90 c0cbdd54 00000000
[   18.717529] 1f40: 00000001 c0124584 51b8dc60 00000004 c0cb8a9c c0c09fa0 cfb3ba58 c05a8e14
[   18.726654] 1f60: 008a43a0 00000000 51b8dc60 00000004 51b8dc60 00000004 c0c029ec c0c00000
[   18.735778] 1f80: c0c029ec 00000000 c0cb8a9c cfb3ba58 c0c09fa0 c0c0298c c0b6ea50 c017bbb4
[   18.744934] 1fa0: c0740760 c0b6a4e4 c0cbd000 ffffffff cfb473c0 c0b00c34 ffffffff ffffffff
[   18.754058] 1fc0: 00000000 c0b0066c 00000000 c0b4fa48 00000000 c0cbd214 c0c0296c c0b4fa44
[   18.763183] 1fe0: c0c08208 80004059 413fc082 00000000 00000000 8000807c 00000000 00000000
[   18.772308] [<c0123750>] (wait_dll_lock_timed) from [<c0c0a0a0>] (omap3_idle_driver+0x100/0x33c)
[   18.782043] Code: 1a000019 e28f708c e59f408c e2844001 (e5874004)

Reverting the $subject patch fixes the issue.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1297615

On Wed, Dec 23, 2015 at 11:51:29AM -0800, Tony Lindgren wrote:
> Also all omap3 boards are now oopsing in Linux next if PM is enabled:

I'm not sure that's entirely true.  My LDP3430 works fine with this
change in place, and that has CONFIG_PM=y.  See my nightly build/boot
results, which includes an attempt to enter hibernation.  Remember
that last night's results are from my tree plus arm-soc's for-next.

Maybe there's some other change in linux-next which, when combined
with this change, is provoking it?

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1297617

* Russell King - ARM Linux <linux@arm.linux.org.uk> [151223 12:01]:
> On Wed, Dec 23, 2015 at 11:51:29AM -0800, Tony Lindgren wrote:
> > Also all omap3 boards are now oopsing in Linux next if PM is enabled:
> 
> I'm not sure that's entirely true.  My LDP3430 works fine with this
> change in place, and that has CONFIG_PM=y.  See my nightly build/boot
> results, which includes an attempt to enter hibernation.  Remember
> that last night's results are from my tree plus arm-soc's for-next.

Right but you don't have any deeper idle states enabled for your
old ldp, see the script below. It may not work properly on your ldp
because of the old silicon revision of the SoC..

> Maybe there's some other change in linux-next which, when combined
> with this change, is provoking it?

Well it seems to be the new default Kconfig options selected by
default as Geert is saying?

And it seems to require off mode enabled for idle to hit it, retention
idle does not seem to trigger it.

Regards,

Tony


8< -------------------------
#!/bin/bash

uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
	echo 3000 > $uart/autosuspend_delay_ms 2>&1
done

uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
for uart in $uarts; do
	echo enabled > $uart/wakeup 2>&1
	echo auto > $uart/control 2>&1
done

echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1297620

On 12/23/2015 11:51 AM, Tony Lindgren wrote:
> * Kees Cook <keescook@chromium.org> [151202 12:31]:
>> The use of CONFIG_DEBUG_RODATA is generally seen as an essential part of
>> kernel self-protection:
>> http://www.openwall.com/lists/kernel-hardening/2015/11/30/13
>> Additionally, its name has grown to mean things beyond just rodata. To
>> get ARM closer to this, we ought to rearrange the names of the configs
>> that control how the kernel protects its memory. What was called
>> CONFIG_ARM_KERNMEM_PERMS is really doing the work that other architectures
>> call CONFIG_DEBUG_RODATA.
>>
>> This redefines CONFIG_DEBUG_RODATA to actually do the bulk of the
>> ROing (and NXing). In the place of the old CONFIG_DEBUG_RODATA, use
>> CONFIG_DEBUG_ALIGN_RODATA, since that's what the option does: adds
>> section alignment for making rodata explicitly NX, as arm does not split
>> the page tables like arm64 does without _ALIGN_RODATA.
>
> Also all omap3 boards are now oopsing in Linux next if PM is enabled:
>
> [   18.549865] Unable to handle kernel paging request at virtual address c01237dc
> [   18.557830] pgd = cf704000
> [   18.560974] [c01237dc] *pgd=8000041e(bad)
> [   18.565765] Internal error: Oops: 80d [#1] SMP ARM
> [   18.571105] Modules linked in: ledtrig_default_on leds_gpio led_class rtc_twl twl4030_wdt
> [   18.581024] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc6-00003-g1bb2057 #2973
> [   18.589508] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [   18.596466] task: c0c06638 ti: c0c00000 task.ti: c0c00000
> [   18.602539] PC is at wait_dll_lock_timed+0x8/0x14
> [   18.607849] LR is at save_context_wfi+0x24/0x28
> [   18.612976] pc : [<c0123750>]    lr : [<c01236b0>]    psr: 600e0093
> [   18.612976] sp : c0c01ea0  ip : c0c028d4  fp : 00000002
> [   18.625549] r10: 00000000  r9 : ffffffff  r8 : 00000000
> [   18.631378] r7 : c01237d8  r6 : 00000003  r5 : 0000000a  r4 : 00000001
> [   18.638610] r3 : 00000004  r2 : 00000006  r1 : f03fe03a  r0 : 0a000023
> [   18.645843] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
> [   18.653839] Control: 10c53879  Table: 8f704019  DAC: 00000051
> [   18.660217] Process swapper/0 (pid: 0, stack limit = 0xc0c00218)
> [   18.666900] Stack: (0xc0c01ea0 to 0xc0c02000)
> [   18.671936] 1ea0: 00000030 c0c01efc 00000003 00000001 00000000 c0c0a0a0 c0c028d4 00000000
> [   18.681060] 1ec0: c0122ef8 00000000 c010d210 8f0b0000 c0c01efc 80119dc0 00000000 00000000
> [   18.690185] 1ee0: 00000000 00000051 80004019 10c5387d 000000e2 00f00000 00000000 c0c06638
> [   18.699279] 1f00: cf6a4e00 00000003 00000001 00000000 c0c0a0a0 00000000 00000000 c010d3bc
> [   18.708404] 1f20: c0cbd460 c0cbdd14 00000003 c012308c 00000003 c0c09f90 c0cbdd54 00000000
> [   18.717529] 1f40: 00000001 c0124584 51b8dc60 00000004 c0cb8a9c c0c09fa0 cfb3ba58 c05a8e14
> [   18.726654] 1f60: 008a43a0 00000000 51b8dc60 00000004 51b8dc60 00000004 c0c029ec c0c00000
> [   18.735778] 1f80: c0c029ec 00000000 c0cb8a9c cfb3ba58 c0c09fa0 c0c0298c c0b6ea50 c017bbb4
> [   18.744934] 1fa0: c0740760 c0b6a4e4 c0cbd000 ffffffff cfb473c0 c0b00c34 ffffffff ffffffff
> [   18.754058] 1fc0: 00000000 c0b0066c 00000000 c0b4fa48 00000000 c0cbd214 c0c0296c c0b4fa44
> [   18.763183] 1fe0: c0c08208 80004059 413fc082 00000000 00000000 8000807c 00000000 00000000
> [   18.772308] [<c0123750>] (wait_dll_lock_timed) from [<c0c0a0a0>] (omap3_idle_driver+0x100/0x33c)
> [   18.782043] Code: 1a000019 e28f708c e59f408c e2844001 (e5874004)
>
> Reverting the $subject patch fixes the issue.
>
> Regards,
>
> Tony
>

Looks like a case similar to Geert's

         adr     r7, kick_counter
wait_dll_lock_timed:
         ldr     r4, wait_dll_lock_counter
         add     r4, r4, #1
         str     r4, [r7, #wait_dll_lock_counter - kick_counter]
         ldr     r4, sdrc_dlla_status
         /* Wait 20uS for lock */
         mov     r6, #8


kick_counter and wait_dll_lock_counter are in the text section which is marked read only.
They need to be moved to the data section along with a few other variables from what I
can tell (maybe those are read only?).

I suspect this is going to be a common issue with suspend/resume code paths since those
are hand written assembly.

Thanks,
Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1297645

Hi,

* Laura Abbott <labbott@redhat.com> [151223 12:31]:
> 
> Looks like a case similar to Geert's
> 
>         adr     r7, kick_counter
> wait_dll_lock_timed:
>         ldr     r4, wait_dll_lock_counter
>         add     r4, r4, #1
>         str     r4, [r7, #wait_dll_lock_counter - kick_counter]
>         ldr     r4, sdrc_dlla_status
>         /* Wait 20uS for lock */
>         mov     r6, #8
> 
> 
> kick_counter and wait_dll_lock_counter are in the text section which is marked read only.
> They need to be moved to the data section along with a few other variables from what I
> can tell (maybe those are read only?).

Thanks for looking, yeah so it seem.

> I suspect this is going to be a common issue with suspend/resume code paths since those
> are hand written assembly.

Yes I suspect we have quite a few cases like this.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1297662

On Wed, 23 Dec 2015, Tony Lindgren wrote:

> Hi,
> 
> * Laura Abbott <labbott@redhat.com> [151223 12:31]:
> > 
> > Looks like a case similar to Geert's
> > 
> >         adr     r7, kick_counter
> > wait_dll_lock_timed:
> >         ldr     r4, wait_dll_lock_counter
> >         add     r4, r4, #1
> >         str     r4, [r7, #wait_dll_lock_counter - kick_counter]
> >         ldr     r4, sdrc_dlla_status
> >         /* Wait 20uS for lock */
> >         mov     r6, #8
> > 
> > 
> > kick_counter and wait_dll_lock_counter are in the text section which is marked read only.
> > They need to be moved to the data section along with a few other variables from what I
> > can tell (maybe those are read only?).
> 
> Thanks for looking, yeah so it seem.
> 
> > I suspect this is going to be a common issue with suspend/resume code paths since those
> > are hand written assembly.
> 
> Yes I suspect we have quite a few cases like this.

We fixed a bunch of similar issues where code was located in the .data 
section for ease of use from assembly code.  See commit b4e61537 and 
d0776aff for example.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1297697

* Nicolas Pitre <nicolas.pitre@linaro.org> [151223 13:45]:
> On Wed, 23 Dec 2015, Tony Lindgren wrote:
> 
> > Hi,
> > 
> > * Laura Abbott <labbott@redhat.com> [151223 12:31]:
> > > 
> > > Looks like a case similar to Geert's
> > > 
> > >         adr     r7, kick_counter
> > > wait_dll_lock_timed:
> > >         ldr     r4, wait_dll_lock_counter
> > >         add     r4, r4, #1
> > >         str     r4, [r7, #wait_dll_lock_counter - kick_counter]
> > >         ldr     r4, sdrc_dlla_status
> > >         /* Wait 20uS for lock */
> > >         mov     r6, #8
> > > 
> > > 
> > > kick_counter and wait_dll_lock_counter are in the text section which is marked read only.
> > > They need to be moved to the data section along with a few other variables from what I
> > > can tell (maybe those are read only?).
> > 
> > Thanks for looking, yeah so it seem.
> > 
> > > I suspect this is going to be a common issue with suspend/resume code paths since those
> > > are hand written assembly.
> > 
> > Yes I suspect we have quite a few cases like this.
> 
> We fixed a bunch of similar issues where code was located in the .data 
> section for ease of use from assembly code.  See commit b4e61537 and 
> d0776aff for example.

Thanks hey some assembly fun for the holidays :) I also need to check what
all gets relocated to SRAM here.

In any case, seems like the $subject patch is too intrusive for v4.5 at
this point.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1297702

On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote:
> * Nicolas Pitre <nicolas.pitre@linaro.org> [151223 13:45]:
> > We fixed a bunch of similar issues where code was located in the .data 
> > section for ease of use from assembly code.  See commit b4e61537 and 
> > d0776aff for example.
> 
> Thanks hey some assembly fun for the holidays :) I also need to check what
> all gets relocated to SRAM here.
> 
> In any case, seems like the $subject patch is too intrusive for v4.5 at
> this point.

Given Christmas and an unknown time between that and the merge window
actually opening, I decided Tuesday would be the last day I take any
patches into my tree - and today would be the day that I drop anything
that causes problems.

So, I've already dropped this, so tomorrow's linux-next should not have
this change.

You'll still see breakage if people enable RODATA though, but that's no
different from previous kernels.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web