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

[Jean-Christian de Rivaz <jc@eclis.ch>]

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