Re: unkillable mount_smbfs processes

From: Kostik Belousov <kostikbel_at_gmail.com>
Date: Tue, 24 Oct 2006 12:56:03 +0300
On Tue, Oct 24, 2006 at 01:02:08AM +0200, Michal Mertl wrote:
> Andrey V. Elsukov wrote:
> > Hi,
> > 
> > My system is CURRENT (~15.10.2006).
> > When I try mounting a smbfs from windows server then
> > mount_smbfs command is don't finished. And i can't
> > interrupt or kill these processes.
> > 
> > ps, top and trace output from ddb attached.
> 
> > last pid:  2146;  load averages:  0.00,  0.00,  0.00    up 0+05:28:50  13:07:20
> > 32 processes:  1 running, 31 sleeping
> > CPU states:     % user,     % nice,     % system,     % interrupt,     % idle
> > Mem: 25M Active, 269M Inact, 73M Wired, 23M Cache, 53M Buf, 36M Free
> > Swap: 1024M Total, 16K Used, 1024M Free
> >  
> >   PID USERNAME    THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
> >   859 root          1  -8    0  6120K  1528K devdrn   0:00  0.00% mount_smbfs
> >   946 root          1  -8    0  6120K  1000K devdrn   0:00  0.00% mount_smbfs
> > 
> 
> 
> Probably unrelated...
> 
> Do you run with the alternative pseudo-terminal implementation
> (kern.pts.enable=1)?
> 
> A situation like this - something stuck in devdrn, has been reported
> before. The problem reported was with portupgrade and xterm
> (gnome-terminal) being stuck (on exit?). I had the problem too until I
> switched back to the default ptys.
> 
> CCing: kib_at_ who I believe has been around the changes before the first
> report.

The "devdrn" state was introduced by Tor Egge commit into sys/kern/kern_conf.c,
rev. 1.199. It prevents access to the freed kernel memory. Basically, some
thread has declared use of the cdev, and thread that executing destroy_devl()
waits until all cdev users release it.

Tty subsystem has problems with locking/reference counting. (At least)
workarounds for them are under development now.

In your case, smb_dev calls destroy_dev() from the d_close() routine.
Since devfs_close() takes the thread reference on the device, that
causes deadlock.


Received on Tue Oct 24 2006 - 07:56:10 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC