Bug#408635: slattach only works every other time
Package: linux-source-2.6.18
Version: 2.6.18-7
When I use the slattach command to set up a SLIP link it works fine the
first time.
If I then kill the slattach process and reissue the command it fails
with error:
SLIP_set_disc(1): File exists
Running slattach once more works.
dmesg shows some interesting information :
kobject_add failed for sl0 with -EEXIST, don't try to register things
with the same name in the same directory.
[<c01b7b54>] kobject_add+0x147/0x16d
[<c0211209>] class_device_add+0x9d/0x3b3
[<c022829d>] register_netdevice+0x21a/0x2d0
[<c8903213>] slip_open+0x3a1/0x4e2 [slip]
[<c01fc709>] tty_ioctl+0x922/0xbac
[<c0117778>] default_wake_function+0x0/0xc
[<c01fd4bd>] n_tty_open+0x0/0x88
[<c01fd498>] n_tty_close+0x0/0x25
[<c01fd3ae>] n_tty_flush_buffer+0x0/0x3b
[<c01fd2ab>] n_tty_chars_in_buffer+0x0/0x5b
[<c01fe5eb>] read_chan+0x0/0x551
[<c01fd545>] write_chan+0x0/0x294
[<c01fef41>] n_tty_ioctl+0x0/0x40d
[<c01fd082>] n_tty_set_termios+0x0/0x1cc
[<c01fe4d2>] normal_poll+0x0/0x119
[<c01fd7d9>] n_tty_receive_buf+0x0/0xcf9
[<c01fd24e>] n_tty_write_wakeup+0x0/0x27
[<c88b2474>] parport_pc_interrupt+0x1a/0x42 [parport_pc]
[<c013fb83>] handle_IRQ_event+0x23/0x49
[<c013fc5c>] __do_IRQ+0xb3/0xe8
[<c013fc80>] __do_IRQ+0xd7/0xe8
[<c0130170>] hrtimer_run_queues+0xcf/0x157
[<c016937b>] do_ioctl+0x47/0x5d
[<c01695db>] vfs_ioctl+0x24a/0x25c
[<c0121c58>] tasklet_action+0x55/0xaf
[<c0169635>] sys_ioctl+0x48/0x5f
[<c0102c11>] sysenter_past_esp+0x56/0x79
How to reproduce (requires a machine with serial port on ttyS0 but
nothing needs to be connected to it):
debian-qemu:~# slattach -L -vd -p slip -s 115200 /dev/ttyS0
slattach: tty_open: looking for lock
slattach: tty_open: trying to open /dev/ttyS0
slattach: tty_open: /dev/ttyS0 (fd=3) slattach: tty_set_speed: 115200
slattach: tty_set_databits: 8
slattach: tty_set_stopbits: 1
slattach: tty_set_parity: N
slip started on /dev/ttyS0 interface sl0
Above is OK, now kill process with CTRL-C
slattach: tty_set_speed: 0
debian-qemu:~#
debian-qemu:~# slattach -L -vd -p slip -s 115200 /dev/ttyS0
slattach: tty_open: looking for lock
slattach: tty_open: trying to open /dev/ttyS0
slattach: tty_open: /dev/ttyS0 (fd=3) slattach: tty_set_speed: 115200
slattach: tty_set_databits: 8
slattach: tty_set_stopbits: 1
slattach: tty_set_parity: N
SLIP_set_disc(1): File exists
debian-qemu:~#
debian-qemu:~# dmesg
Gives trace shown above
Note that the same problem occurs on real hardware not just qemu (I'm
submitting this from home and my etch system doesn't have a serial port)
The problem does NOT occur on a Sarge system with a 2.6.8 kernel
My analysis (for what it's worth - I'm not a kernel hacker)
Looking at the kernel SLIP driver it appears to pool network devices.
sl_alloc first frees the pooled device with unregister_netdevice before
reregistering it.
Hence for each slip_open (after the first one) there is a call to
unregister_netdevice then register_netdevice
But unregister_netdevice (in net/core/net/dev.c) does not directly free
the sysfs entries but schedules it to be done later by netdev_run_todo)
Thus a race condition seems to exist in the SLIP usage case.
Regards,
Martin
Reply to: