From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank van Maarseveen Subject: 2.6.19.3 client locking bug upon server reboot Date: Mon, 26 Feb 2007 15:15:17 +0100 Message-ID: <20070226141517.GA22552@janus> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Linux NFS mailing list Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1HLgdM-0004gP-SX for nfs@lists.sourceforge.net; Mon, 26 Feb 2007 06:15:21 -0800 Received: from frankvm.xs4all.nl ([80.126.170.174] helo=janus.localdomain) by mail.sourceforge.net with esmtp (Exim 4.44) id 1HLgdN-00070f-EX for nfs@lists.sourceforge.net; Mon, 26 Feb 2007 06:15:23 -0800 List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net 2.6.19.3, NFS V3, portmap V2, stat V1, nlm, all UDP one server, three clients: client1 has the lock client2 wants the lock (fcntl blocks) client3 will try to lock right after server has rebooted and started everything On the server, /etc/rc2.d/S06xxxx is created to start a tcpdump -i eth0 -p -w /tmp/log -s 1500 >/dev/null 2>&1 & upon the next reboot right after eth0 becomes up. I type alt-sysrq-b on the server after a few "sync" commands. After >5 minutes client1 releases the lock and client3 obtains the lock. A few seconds later client3 releases the lock. nothing happens client2 did not try to obtain a lock anyhow since server reboot. Instead, it hangs in rpc_wait_bit_interruptible(), only kill -9 could kill it. The log written by tcpdump has been analyzed afterwards using wireshark (t=