From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753170AbdKHXoc (ORCPT ); Wed, 8 Nov 2017 18:44:32 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:56526 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752741AbdKHXob (ORCPT ); Wed, 8 Nov 2017 18:44:31 -0500 Date: Wed, 8 Nov 2017 15:44:29 -0800 From: Andrew Morton To: Tetsuo Handa Cc: clingutla@codeaurora.org, kimran@codeaurora.org, mingo@kernel.org, peterz@infradead.org, mcgrof@kernel.org, keescook@chromium.org, shile.zhang@nokia.com, matt@codeblueprint.co.uk, vegard.nossum@oracle.com, jsiddle@redhat.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC] hung task: check specific tasks for long uninterruptible sleep state Message-Id: <20171108154429.909e12c5f7141cde37416469@linux-foundation.org> In-Reply-To: <201711082057.IDF56726.OMHOSFVFJtQOFL@I-love.SAKURA.ne.jp> References: <1503311156-16919-1-git-send-email-kimran@codeaurora.org> <20171108062813.25240-1-clingutla@codeaurora.org> <201711082057.IDF56726.OMHOSFVFJtQOFL@I-love.SAKURA.ne.jp> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 8 Nov 2017 20:57:42 +0900 Tetsuo Handa wrote: > Lingutla Chandrasekhar wrote: > > Some tasks may intentionally moves to uninterruptable sleep state, > > which shouldn't leads to khungtask panics, as those are recoverable > > hungs. So to avoid false hung reports, add an option to select tasks > > to be monitored and report/panic them only. > > What are backtraces of such tasks? Please point the locations in the code. > > If they are absolutely recoverable, why can't we let themselves declare that > "I'm intentionally in uninterruptible state. But there is no dependency that > prevents me from recovering. So, please ignore me." using per "struct > task_struct" flags rather than introducing userspace controlled interface? Yes. Please tell us much much much more about the use case and scenarios which inspired this change.