From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755450AbcH2TFA (ORCPT ); Mon, 29 Aug 2016 15:05:00 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:53158 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752808AbcH2TE6 (ORCPT ); Mon, 29 Aug 2016 15:04:58 -0400 Subject: Re: [PACTH v1] kernel/hung_task.c: Dump all UNINTERUPTIBLE tasks To: Andrew Morton References: <1470151391-16420-1-git-send-email-robert.foss@collabora.com> <20160810154345.f0c34d0936b0835b541405b0@linux-foundation.org> <9a55596a-7176-cf88-243d-ad599b6b421f@collabora.com> Cc: adurbin@chromium.org, penguin-kernel@I-love.SAKURA.ne.jp, linux-kernel@vger.kernel.org From: Robert Foss Message-ID: Date: Mon, 29 Aug 2016 15:04:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9a55596a-7176-cf88-243d-ad599b6b421f@collabora.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@collabora.com wrote: >> >>> From: Aaron Durbin >>> >>> 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?