[patch 1/6] tty_port: allow a port to be opened with a tty that has no file handle

[Samuel Thibault]

Okash Khawaja, on mer. 17 mai 2017 08:44:19 +0100, wrote:
> On Sun, Feb 26, 2017 at 1:05 AM, Samuel Thibault
> <samuel.thibault at ens-lyon.org> wrote:
> > Samuel Thibault, on dim. 26 févr. 2017 01:53:42 +0100, wrote:
> >> Okash Khawaja, on sam. 25 févr. 2017 19:21:32 +0000, wrote:
> >> > Allow access to TTY device from kernel.
> >>
> >> When opening the TTY from an application (e.g. echo foo > /dev/ttyS0),
> >> we get this:
> >>
> >> ttyS ttyS0: tty_open: tty->count(3) != #fd's(2)
> >> ttyS ttyS0: tty_release: tty->count(3) != #fd's(2)
> >>
> >> This is because the number of files in tty_files doesn't match the
> >> open count for tty. spk_ttyio_initialise_ldisc should thus mimic
> >> tty_open a bit more: after calling tty_open_by_driver, it should call
> >> tty_add_file(tty, NULL); to add an entry in the tty_files list (and why
> >> not calling check_tty_count too).  And of course, the converse
> >> (tty_del_file) should be called by spk_ttyio_release between the
> >> tty_ldisc_flush call and tty_unlock.
> >
> > Oops, of course you don't have a filp to give to tty_del_file, so that
> > can't work. Ok, let's ignore the issue for now, applications are not
> > supposed to open the tty used by speakup anyway (and would get an EIO
> > error anyway).
> 
> This issue with opening tty from userspace while it's in use from kernel. Wonder
> if this will rear its ugly head with rescpect to the recent patches?

Ah, yes, we will have to think about that issue.

Samuel