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
| ||
|
Date: Mon, 29 Aug 2016 15:04:51 -0400 From: Robert Foss <robert.foss@...labora.com> To: Andrew Morton <akpm@...ux-foundation.org> Cc: adurbin@...omium.org, penguin-kernel@...ove.SAKURA.ne.jp, linux-kernel@...r.kernel.org Subject: Re: [PACTH v1] kernel/hung_task.c: Dump all UNINTERUPTIBLE tasks On 2016-08-11 12:35 PM, Robert Foss wrote: > > > On 2016-08-10 06:43 PM, Andrew Morton wrote: >> On Tue, 2 Aug 2016 11:23:11 -0400 robert.foss@...labora.com wrote: >> >>> From: Aaron Durbin <adurbin@...omium.org> >>> >>> When the panic path is taken for khungtaskd dump all >>> tasks with the UNINTERUPTIBLE state. That way, any >>> inter-dependent tasks that caused one another to hang >>> will be saved in the crash output. >>> >>> ... >>> >>> --- a/kernel/hung_task.c >>> +++ b/kernel/hung_task.c >>> @@ -122,6 +122,8 @@ static void check_hung_task(struct task_struct >>> *t, unsigned long timeout) >>> touch_nmi_watchdog(); >>> >>> if (sysctl_hung_task_panic) { >>> + /* Dump all tasks. */ >>> + show_state_filter(TASK_UNINTERRUPTIBLE); >>> trigger_all_cpu_backtrace(); >>> panic("hung_task: blocked tasks"); >>> } >> >> Well, it's going to produce more gunk for the operator to read through >> and understand. >> >> I'd like to hear a little more about the value of this change: what >> particular problem prompted it, etc. >> > > It would indeed provide more gunk. What makes it useful is that is on > enabled by default and enables rapid debugging of devices that are not > physically accessible or accessible for debugging otherwise. > > So the primary usecase would be when a user of a device is seeing some > issues and submits the logs from the device. > Without any further action from the user, the problem could potentially > be solved. The debug output could be formatted better, would that make this patch more appealing?
Powered by blists - more mailing lists