linux-kernel - Re: 2.6.16.32 stuck in generic_file_aio

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: <Pine.LNX.4.58.0612070940590.28683@jdi.jdi-ict.nl>
Date:	Thu, 7 Dec 2006 10:58:45 +0100 (CET)
From:	Igmar Palsenberg <i.palsenberg@...-ict.nl>
To:	Andrew Morton <akpm@...l.org>
cc:	linux-kernel@...r.kernel.org, npiggin@...e.de,
	erich <erich@...ca.com.tw>
Subject: Re: 2.6.16.32 stuck in generic_file_aio_write()

> I thought it was, but from my look through yout 8-billion-task backtrace,
> no task was stuck in D-state with the appropriate call trace.

I was afraid of that... Where is the lock on the i_mutex suppose 
to be released ? I can't grasp the codepath from within an interrupt back 
to the fs layer.

> So I don't know what's causing this.  In the first trace you have at least
> four D-state kjournalds and a lot of processes stuck on an i_mutex.  I
> guess it's consistent with an IO system which is losing completion
> interrupts.  AFAICT in the second trace all you have is a lot of processes
> stuck on i_mutex for no obvious reason - I don't know why that would
> happen.

Is there any way to see if it is missing interrupts ? Enabling the 
debugging in the areca driver isn't a good idea on this machine, it's a
heavely IO loaded machine, and the problem seems to take some time to occur.

I *does* happen less often with a 2.6.19 kernel however. 

The task dump takes > 10 seconds, which causes the softlock detector to 
trigger. Is there any objection to a patch which disables the lockup 
detector during the dump ? It isn't a big issue, since al it does is dump 
a stacktrace.

I've enabled most debugging now, I'll see of i can run both a disk and VM 
stresstest.

I'll put a .config and a dmesg of the machine booting at 
http://www.jdi-ict.nl/plain/ for those who want to look at it.

Regards,

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