linux-kernel - Re: [PATCH] drm: avoid switching to text console if there is no panic timeout

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABqxG0ekuqGDiFRsE9p1J2FubWo3J+SufwuUC=56JCSF3dVoTA@mail.gmail.com>
Date:	Wed, 19 Oct 2011 09:07:12 +0800
From:	Dave Young <hidave.darkstar@...il.com>
To:	Mandeep Singh Baines <msb@...omium.org>
Cc:	linux-kernel@...r.kernel.org, David Airlie <airlied@...ux.ie>,
	Hugh Dickins <hughd@...omium.org>,
	Hugh Dickins <hughd@...gle.com>,
	Dave Airlie <airlied@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	dri-devel@...ts.freedesktop.org, marcheu@...omium.org,
	rientjes@...gle.com
Subject: Re: [PATCH] drm: avoid switching to text console if there is no panic timeout

On Wed, Oct 19, 2011 at 2:29 AM, Mandeep Singh Baines <msb@...omium.org> wrote:
> Dave Young (hidave.darkstar@...il.com) wrote:
>> On Tue, Oct 18, 2011 at 10:19 AM, Dave Young <hidave.darkstar@...il.com> wrote:
>> > On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines <msb@...omium.org> wrote:
>> >> From: Hugh Dickins <hughd@...omium.org>
>> >>
>> >> Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
>> >> we're going to reboot immediately, the user will not be able to see the
>> >> messages anyway, and messing with the video mode may display artifacts,
>> >> and certainly get into several layers of complexity (including mutexes and
>> >> memory allocations) which we shall be much safer to avoid.
>> >
>> > There's one exception is use printk_delay
>>
>> OTOH the complexity do exist also when timeout is set, IMHO it is worth
>>
>
> Hi Dave,
>
> I agree. The complexity is worth it if you want to see the panic trace
> on the VT. But if you have the panic_timeout negative (i.e. reboot
> immediately) than you're just add more risk/complexity to panic for no
> benefit.
>
>
> To avoid losing the panic traces, a reliable panic is critical.
>
> In our app, we use panic_timeout=-1 and we use ramoops for capturing panic
> traces. We want the panic path to be as simple as possible to avoid
> wedging machines and to avoid losing panic traces. In our test lab,
> if a machine gets wedged, a human needs to go and power cycle the machine
> to bring it back online.
>
> For user devices, we want to panic quickly and get the device back up
> ASAP. Our reboot time is under 8 seconds so its less than 10 seconds before
> you're back online and surfing the web. We also want to avoid displaying any
> artifacts or traces to the user when panicking.
>
> You bring up a good point about printk_delay. But I'm thinking if you're
> using prink_delay you'd also want to set panic_timeout >= 0. Otherwise,
> you'd reboot immediately after displaying the last line of output.

fair enough, thanks.

>
> Regards,
> Mandeep
>
>> >
>> >>
>> >> Signed-off-by: Hugh Dickins <hughd@...gle.com>
>> >> [ Edited commit message and modified to short-circuit panic_timeout < 0
>> >>  instead of testing panic_timeout >= 0.  -Mandeep ]
>> >> Signed-off-by: Mandeep Singh Baines <msb@...omium.org>
>> >> Cc: Dave Airlie <airlied@...hat.com>
>> >> Cc: Andrew Morton <akpm@...ux-foundation.org>
>> >> Cc: dri-devel@...ts.freedesktop.org
>> >> ---
>> >>  drivers/gpu/drm/drm_fb_helper.c |    7 +++++++
>> >>  1 files changed, 7 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
>> >> index f7c6854..0e62c93 100644
>> >> --- a/drivers/gpu/drm/drm_fb_helper.c
>> >> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> >> @@ -254,6 +254,13 @@ bool drm_fb_helper_force_kernel_mode(void)
>> >>  int drm_fb_helper_panic(struct notifier_block *n, unsigned long ununsed,
>> >>                        void *panic_str)
>> >>  {
>> >> +       /*
>> >> +        * It's a waste of time and effort to switch back to text console
>> >> +        * if the kernel should reboot before panic messages can be seen.
>> >> +        */
>> >> +       if (panic_timeout < 0)
>> >> +               return 0;
>> >> +
>> >>        printk(KERN_ERR "panic occurred, switching back to text console\n");
>> >>        return drm_fb_helper_force_kernel_mode();
>> >>  }
>> >> --
>> >> 1.7.3.1
>> >>
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> >> the body of a message to majordomo@...r.kernel.org
>> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >> Please read the FAQ at  http://www.tux.org/lkml/
>> >>
>> >
>> >
>> >
>> > --
>> > Regards
>> > Dave
>> >
>>
>>
>>
>> --
>> Regards
>> Dave
>



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