linux-kernel - Re: heavy nfs[4]] causes fs badness Was: 2.6.20-rc4: known unfixed regressions (v2)

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.64.0701150109190.16747@twin.jikos.cz>
Date:	Mon, 15 Jan 2007 01:14:09 +0100 (CET)
From:	Jiri Kosina <jikos@...os.cz>
To:	Florin Iucha <florin@...ha.net>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-usb-devel@...ts.sourceforge.net,
	Adrian Bunk <bunk@...sta.de>,
	Alan Stern <stern@...land.harvard.edu>,
	Trond Myklebust <trond.myklebust@....uio.no>
Subject: Re: heavy nfs[4]] causes fs badness Was: 2.6.20-rc4: known unfixed
 regressions (v2)

On Sun, 14 Jan 2007, Florin Iucha wrote:

> All the testing was done via a ssh into the workstation.  The console 
> was left as booted into, with the gdm running.  The remote nfs4 
> directory was mounted on "/mnt". After copying the 60+ GB and testing 
> that the keyboard was still functioning, I did not reboot but stayed in 
> the same kernel and pulled the latest git then started bisecting.  

Hi Florin,

thanks a lot for the testing. Just to verify - what kernel is 'the same 
kernel' mentioned above? (just to isolate whether the problem is really 
somewhere between 2.6.19 and 2.6.20-rc2, as you stated in previous posts, 
or the situation has changed).

> After recompiling, I moved over to the workstation to reboot it, but the 
> keyboard was not functioning ;(

So this time the hang occured when the system was idle, not during the 
transfers, right?

> I ran "lsusb" and it displayed all the devices. "dmesg" did not show
> any oops, anything for that matter.  I have unplugged the keyboard and
> run "lsusb" again, but it hang.  I ran "ls /mnt" and it hang as well.
> Stracing "lsusb" showed it hang (entered the kernel) at opening the device
> that used to be the keyboard.  Stracing "ls /mnt" showed that it
> hang at "stat(/mnt)".  Both processes were in "D" state.  "ls /root"
> worked without problem, so it appears that crossing mountpoints causes
> some hang in the kernel.

Could you please do alt-sysrq-t (or "echo t > /proc/sysrq-trigger" via 
ssh, when your keyboard is dead) to see the calltraces of the processes 
which are stuck inside kernel?

You will probably get a lot of output after the sysrq, so please either 
put it somewhere on the web if possible, or just extract the interesting 
processes out of it (mainly the ones which are stuck).

Thanks,

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