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

[Okash Khawaja]

Hi,

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?