Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1238435
| From | Jean-Christian de Rivaz <jc@eclis.ch> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Force mkiss to reset the line discipline when serial device is removed |
| Date | 2015-10-02 19:30 +0200 |
| Message-ID | <qfcjF-1AV-11@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <qePQ6-2MU-3@gated-at.bofh.it> <qeUZr-1Mq-1@gated-at.bofh.it> <qf42L-6wc-25@gated-at.bofh.it> <qf64y-WZ-11@gated-at.bofh.it> <qf8SK-4YE-37@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Force mkiss to reset the line discipline when serial device is removed Jean-Christian de Rivaz <jc@eclis.ch> - 2015-10-01 19:30 +0200
Re: Force mkiss to reset the line discipline when serial device is removed Peter Hurley <peter@hurleysoftware.com> - 2015-10-02 01:00 +0200
Re: Force mkiss to reset the line discipline when serial device is removed Jean-Christian de Rivaz <jc@eclis.ch> - 2015-10-02 10:40 +0200
Re: Force mkiss to reset the line discipline when serial device is removed Thomas Osterried <thomas@osterried.de> - 2015-10-02 12:50 +0200
Re: Force mkiss to reset the line discipline when serial device is removed Jean-Christian de Rivaz <jc@eclis.ch> - 2015-10-02 15:50 +0200
Re: Force mkiss to reset the line discipline when serial device is removed Jean-Christian de Rivaz <jc@eclis.ch> - 2015-10-02 19:30 +0200
[PATCH 1/1] Add poll method to mkiss let notify hangup to the user process. Jean-Christian de Rivaz <jc@eclis.ch> - 2015-10-02 23:50 +0200
csiph-web