linux-kernel - Re: [feature] automatically detect hung 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071203110412.GD28560@one.firstfloor.org>
Date:	Mon, 3 Dec 2007 12:04:12 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Radoslaw Szkodzinski <lkml@...ralstorm.puszkin.org>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks

On Mon, Dec 03, 2007 at 11:38:15AM +0100, Ingo Molnar wrote:
> 
> * Andi Kleen <andi@...stfloor.org> wrote:
> 
> > > Kernel waiting 2 minutes on TASK_UNINTERRUPTIBLE is certainly broken.
> > 
> > What should it do when the NFS server doesn't answer anymore or when 
> > the network to the SAN RAID array located a few hundred KM away 
> > develops some hickup?  [...]
> 
> maybe: if the user does a Ctrl-C (or a kill -9), the kernel should try 

You mean NFS intr should be default? Traditionally that was not done,
although that decision dates back to long before Linux to original SunOS. 

I was not there but I suspect it was because it is hard to distingush 
between "abort IO" and "abort program". With aborted IO you tend to end up 
with a page in page cache that is marked as IO error and will affect
other programs too.

Perhaps that can be cleanly solved -- personally I'm not sure -- but
it is likely not easy otherwise people would have done that a long
time ago.

> to honor it, instead of staying there stuck for a very long time 
> (possibly forever)?

Sure everybody hates that (it is like trying to argue against
free video games @), but fixing it properly is quite hard. 
I just think it's a bad idea to outlaw it before even attempting
to fix it.

If you consider any of the arguments in the following
paragraph "not rational" please state your objection precisely.
Thanks.

Consider the block case: First a lot of block
IO runs over networks too these days (iSCSI, drbd, nbd, SANs etc.) 
so the same considerations as for other network file systems
apply.  Networks can have hickups and might take long to recover.
Now implementing TASK_KILLABLE in all block IO paths
there properly is equivalent to implementing EIOCBRETRY aio because
it has to error out in near the same ways in all the same
places.  While I would like to see that (and it would probably make syslets
obsolete too ;-) it has been rejected as too difficult in the past.

> I think you are somehow confusing two issues: this patch in no way 
> declares that "long waits are bad" - if the user _choses_ to wait for 

Throwing a backtrace is the kernel's way to declare something as bad.
The only more clear ways to that I know of would be BUG or panic().

> way to stop_ are quite likely bad".

The user will just see the backtraces and think the kernel
has crashed.

-Andi

--
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/