Re: mount deadlock

[Andrew Doran <ad%netbsd.org@localhost>]

On Wed, Jan 09, 2008 at 01:41:10PM +0000, Andrew Doran wrote:

> On Wed, Jan 09, 2008 at 02:03:05PM +0100, Tobias Nygren wrote:
> 
> > On Wed, 9 Jan 2008 13:19:30 +0200
> > Antti Kantee <pooka%cs.hut.fi@localhost> wrote:
> > 
> > > On Wed Jan 09 2008 at 06:07:10 +0100, Tobias Nygren wrote:
> > > > I have other filesystem related problems as well, for example mounting
> > > > a filesystem onto a newly created directory tends to deadlock mount.
> > > 
> > > Hmm, sounds weird.  Is there a PR for this?  I couldn't repeat it with
> > > a quick try.
> > 
> > No PR, but the machine is wedged as of this moment. I didn't bother
> > rebooting it since it's nfsd is still happily serving up files.
> > 
> > Anything particular I could run from DDB to figure out why it's blocking
> > infinitely on the buffer? This is sparc64 btw, and there are no other
> > processes in unusual wait channels from what I can tell. They do get
> > wedged if I try to access the vnode of the mount point.
> > 
> > db> trace/a 2742a340
> > trace: pid 424 lid 1 at 0x275aee61
> > sleepq_block(0, 0, 2742a340, 1, 55, 18a01e0) at netbsd:sleepq_block+0xfc
> > cv_timedwait(18a3e50, 0, 0, 201b, 0, ffffffff80000000) at 
> > netbsd:cv_timedwait+0xe8
> > bbusy(605e490, 0, 0, 0, 0, ffffffff80000000) at netbsd:bbusy+0xac
> > vinvalbuf(3751a420, 1, 605e490, 2742a340, 0, 0) at netbsd:vinvalbuf+0x11c
> > do_sys_mount(16, 18147c0, 3f64240, ffffffffffffa620, ffffffff80000000, 
> > fffffffff fffaa20) at netbsd:do_sys_mount+0x458
> > sys___mount50(2742a340, 275afdc0, 275afe00, 1, 201c20, 1815de0) at 
> > netbsd:sys___ mount50+0x28
> > syscall_plain(275afed0, 5, 4063c7c4, 4063c7c8, 0, 275afdc0) at 
> > netbsd:syscall_plain+0x118
> > ?(101358, ffffffffffffa620, ffffffff80000000, ffffffffffffaa20,8, 0) at 
> > 0x1008d78
> > 
> > Another recent mount issue is that mount -uw / no longer works in
> > single user mode. This I can repeat on i386 as well. I must now specify
> > the device name for this to succeed.
> 
> I noticed this yesterday and can reproduce it. Something is busying a buffer
> and not releasing it later (eg by start I/O on it). I'll have a look.

This is with softdep, right? If so it's fixed.

Andrew