linux-kernel - Re: Hung task detector versus NFS (TASK

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] [day] [month] [year] [list]

Message-ID: <20160309202316.GA21640@hostway.ca>
Date:	Wed, 9 Mar 2016 12:23:16 -0800
From:	Simon Kirby <sim@...tway.ca>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Hung task detector versus NFS (TASK_KILLABLE)

On Mon, Mar 07, 2016 at 07:11:19PM -0800, Andi Kleen wrote:

> > I write this because I would actually find it useful to see the original
> > backtrace, even if it is interruptible, not just the collateral damage.
> > Since the "skipping" of NFS is basically incomplete anyway, how big a
> > deal is this "feature"?
> 
> Random backtrace spewing is always a misfeature for 99.99+% of the users
> for whom it is gibberish.

Distributions all seem to ship with it on because apparently some people
can read it. There was even discussion that the default 10 is not enough.

> If you really need it yourself add a kprobe.

To emulate a hung task backtrace even when TASK_KILLABLE? That sounds
like some hoop-jumping, but I don't know kprobes.

I'm just saying the current "NFS filter" is broken ("cat a" twice), but
this really will make more noise for people (in cases where NFS is stuck
for minutes), I guess I'll just sit in a corner with that line changed in
my tree.

Simon-