Re: Force mkiss to reset the line discipline when serial device is removed

From: Jean-Christian de Rivaz
Date: Fri Oct 02 2015 - 13:25:35 EST


Le 02. 10. 15 15:48, Jean-Christian de Rivaz a écrit :
Le 02. 10. 15 12:35, Thomas Osterried a écrit :

I also wonder why userspace processes like kissattach do not get a signal by the kernel, indicating that the filedescriptor is not valid anymore.
Who’s job would it be to signal, the serial driver’s (slip, ppp, mkiss, ..), or ldisc’s?

It's a complete other problem, not kernel related. The safety of the kernel cannot depend on a user application closing a file descriptor. Even if the user application close his file descriptor, process scheduling can make this delayed long enough to let's a packet reach the parasitic uninitialized interface and completely crash the system. This will at best only reduce the race window but do nothing to fix the real bug. That said, kissattach uses a while (1) { sleep(); } loop that can be cheaply replaced by a single old select() waiting on the file descriptor. My understanding is that after the the AX25 discipline is in place the only event that can happen is that the descriptor is to be closed. I will test a kissattach patch for this.

AFAIK tty_ldisc_hangup() already signal EOF to the file descriptor owner with these lines:

wake_up_interruptible_poll(&tty->write_wait, POLLOUT);
wake_up_interruptible_poll(&tty->read_wait, POLLIN);


I was completely wrong on this. The kissattach application get no event at all. I tried with select() and poll().

You are right, something is missing in the kernel to notify EOF in the descriptor of a removed serial device when at least the N_AX25 line discipline is used. The EOF is notified correctly at least in the case of the N_TTY line discipline.

So your question make sense: who must send the EOF ? Maybe it's the line discipline code.

Greg, Jiri, can you give some hint ?

Best Regards,
Jean-Christian de Rivaz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/