unaddressed issues around tty_open_by_driver

unaddressed issues around tty_open_by_driver

[Okash Khawaja]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

Hi,

Raising this here but I think we will ultimately discuss this on a wider
mailing list.

There are three issues I can see with the way we open tty from speakup
(and others will also have similar problems if they use
tty_open_by_kernel).

1. user space opens tty which is already opened by kernel
2. kernel opens tty that is already opened by user
3. user space opens tty kernel has stopped using

First two may be addressed by checking flags before opening and
setting and unsetting those flags after opening and before closing.

Third one is interesting. I haven't investigated it yet, but it seems to
throw a kernel oops from tty_ldisc_reinit. I have attached relevant bit
from kernel log - please see from line at 08:37:03 onwards. I ran `echo
foo > /dev/ttyUSB0` after unloading speakup and speakup_apollo which
were loaded with dev=ttyUSB0.

We can avoid 2 and 3 above by calling tty_open_by_driver only when
speakup is built into kernel and not when loaded as module. Which of
course means we need to work out what to do when loading speakup as
module.

Thanks,
Okash

[-- Attachment #2: tty-kernel.log --]
[-- Type: text/plain, Size: 5776 bytes --]

[Sun Jun 25 08:33:07 2017] speakup: loading out-of-tree module taints kernel.
[Sun Jun 25 08:33:07 2017] speakup: module is from the staging directory, the quality is unknown, you have been warned.
[Sun Jun 25 08:33:07 2017] input: Speakup as /devices/virtual/input/input19
[Sun Jun 25 08:33:07 2017] initialized device: /dev/synth, node (MAJOR 10, MINOR 25)
[Sun Jun 25 08:33:07 2017] speakup 3.1.6: initialized
[Sun Jun 25 08:33:07 2017] synth name on entry is: (null)
[Sun Jun 25 08:33:29 2017] speakup_apollo: module is from the staging directory, the quality is unknown, you have been warned.
[Sun Jun 25 08:33:29 2017] synth probe
[Sun Jun 25 08:34:16 2017] ttyUSB ttyUSB0: tty_open: tty->count(2) != #fd's(1)
[Sun Jun 25 08:34:16 2017] ttyUSB ttyUSB0: tty_release: tty->count(2) != #fd's(1)
[Sun Jun 25 08:36:19 2017] releasing synth apollo
[Sun Jun 25 08:36:22 2017] speakup: unregistering synth device /dev/synth
[Sun Jun 25 08:37:03 2017] BUG: unable to handle kernel paging request at ffffffffa09a9348
[Sun Jun 25 08:37:03 2017] IP: get_ldops+0x2b/0x70
[Sun Jun 25 08:37:03 2017] PGD 1a0c067
[Sun Jun 25 08:37:03 2017] PUD 1a0d063
[Sun Jun 25 08:37:03 2017] PMD 113b8b067
[Sun Jun 25 08:37:03 2017] PTE 0

[Sun Jun 25 08:37:03 2017] Oops: 0000 [#1] PREEMPT SMP
[Sun Jun 25 08:37:03 2017] Modules linked in: pl2303 usbserial ctr ccm joydev uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev arc4 gpio_ich iTCO_wdt iTCO_vendor_support media iwldvm dell_wmi sparse_keymap mac80211 dell_rbtn ppdev dell_laptop dell_smbios dcdbas coretemp iwlwifi kvm_intel dell_smm_hwmon kvm irqbypass cfg80211 snd_hda_codec_hdmi nfnetlink_log rfkill nfnetlink snd_hda_codec_idt snd_hda_codec_generic psmouse pcspkr i2c_i801 i915 cdc_ether usbnet cdc_wdm mii cdc_acm lpc_ich shpchp snd_hda_intel mousedev evdev input_leds mac_hid snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore drm_kms_helper thermal acpi_als wmi battery kfifo_buf button drm parport_pc syscopyarea e1000e parport sysfillrect intel_agp industrialio sysimgblt fb_sys_fops ptp intel_gtt
[Sun Jun 25 08:37:03 2017]  i2c_algo_bit pps_core video ac acpi_cpufreq tpm_tis tpm_tis_core tpm sch_fq_codel sg ip_tables x_tables ext4 crc16 jbd2 fscrypto mbcache sr_mod cdrom sd_mod hid_generic usbhid hid uhci_hcd serio_raw atkbd libps2 ahci libahci firewire_ohci sdhci_pci sdhci led_class mmc_core firewire_core libata crc_itu_t scsi_mod ehci_pci ehci_hcd usbcore usb_common i8042 serio [last unloaded: speakup]
[Sun Jun 25 08:37:03 2017] CPU: 0 PID: 738 Comm: bash Tainted: G         C O    4.11.3-ARCH-dirty #11
[Sun Jun 25 08:37:03 2017] Hardware name: Dell Inc. Latitude E4300                  /0D201R, BIOS A13 10/29/2009
[Sun Jun 25 08:37:03 2017] task: ffff8801073b8d00 task.stack: ffffc90000648000
[Sun Jun 25 08:37:03 2017] RIP: 0010:get_ldops+0x2b/0x70
[Sun Jun 25 08:37:03 2017] RSP: 0018:ffffc9000064bb00 EFLAGS: 00010086
[Sun Jun 25 08:37:03 2017] RAX: 0000000000000293 RBX: ffffffffa09a92c0 RCX: 0000000000000003
[Sun Jun 25 08:37:03 2017] RDX: 0000000000000001 RSI: 000000000000001a RDI: ffffffff81d26670
[Sun Jun 25 08:37:03 2017] RBP: ffffc9000064bb10 R08: 0000000000000002 R09: ffffffff8141d612
[Sun Jun 25 08:37:03 2017] R10: 0000000000000000 R11: ffff8800d838c3c0 R12: 0000000000000293
[Sun Jun 25 08:37:03 2017] R13: ffff880104d6c800 R14: ffffffff8186e760 R15: ffff88008c4cfe10
[Sun Jun 25 08:37:03 2017] FS:  00007f7a17a44b40(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000
[Sun Jun 25 08:37:03 2017] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[Sun Jun 25 08:37:03 2017] CR2: ffffffffa09a9348 CR3: 000000008c56a000 CR4: 00000000000406f0
[Sun Jun 25 08:37:03 2017] Call Trace:
[Sun Jun 25 08:37:03 2017]  tty_ldisc_get.part.1+0x1b/0xa0
[Sun Jun 25 08:37:03 2017]  tty_ldisc_reinit+0x37/0x100
[Sun Jun 25 08:37:03 2017]  tty_reopen+0x6a/0x80
[Sun Jun 25 08:37:03 2017]  tty_open_by_driver+0x216/0x250
[Sun Jun 25 08:37:03 2017]  tty_open+0x16b/0x2d0
[Sun Jun 25 08:37:03 2017]  chrdev_open+0xb0/0x1e0
[Sun Jun 25 08:37:03 2017]  do_dentry_open+0x20a/0x2f0
[Sun Jun 25 08:37:03 2017]  ? cdev_put+0x30/0x30
[Sun Jun 25 08:37:03 2017]  vfs_open+0x4e/0x80
[Sun Jun 25 08:37:03 2017]  path_openat+0x2c9/0x1170
[Sun Jun 25 08:37:03 2017]  ? alloc_set_pte+0x259/0x600
[Sun Jun 25 08:37:03 2017]  do_filp_open+0x99/0x110
[Sun Jun 25 08:37:03 2017]  ? __check_object_size+0x54/0x196
[Sun Jun 25 08:37:03 2017]  ? __alloc_fd+0xb2/0x160
[Sun Jun 25 08:37:03 2017]  do_sys_open+0x147/0x210
[Sun Jun 25 08:37:03 2017]  ? do_sys_open+0x147/0x210
[Sun Jun 25 08:37:03 2017]  SyS_open+0x1e/0x20
[Sun Jun 25 08:37:03 2017]  entry_SYSCALL_64_fastpath+0x1a/0xa9
[Sun Jun 25 08:37:03 2017] RIP: 0033:0x7f7a17128120
[Sun Jun 25 08:37:03 2017] RSP: 002b:00007ffd3b37d498 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
[Sun Jun 25 08:37:03 2017] RAX: ffffffffffffffda RBX: 000000000259ab20 RCX: 00007f7a17128120
[Sun Jun 25 08:37:03 2017] RDX: 00000000000001b6 RSI: 0000000000000241 RDI: 000000000259ab20
[Sun Jun 25 08:37:03 2017] RBP: 0000000000000001 R08: 0000000000000020 R09: 0000000000000000
[Sun Jun 25 08:37:03 2017] R10: 00000000025966c0 R11: 0000000000000246 R12: 0000000000000020
[Sun Jun 25 08:37:03 2017] R13: 0000000000000003 R14: 0000000000000001 R15: 000000000259ab20
[Sun Jun 25 08:37:03 2017] Code: 66 66 66 66 90 55 48 89 e5 41 54 53 48 63 df 48 c7 c7 70 66 d2 81 e8 f5 28 21 00 48 8b 1c dd 80 65 d2 81 49 89 c4 48 85 db 74 37 <48> 8b bb 88 00 00 00 e8 99 87 ce ff 84 c0 74 1e 83 83 90 00 00
[Sun Jun 25 08:37:03 2017] RIP: get_ldops+0x2b/0x70 RSP: ffffc9000064bb00
[Sun Jun 25 08:37:03 2017] CR2: ffffffffa09a9348
[Sun Jun 25 08:37:03 2017] ---[ end trace 158d4b4e7aed864d ]---
[Sun Jun 25 08:37:03 2017] note: bash[738] exited with preempt_count 1

Re: unaddressed issues around tty_open_by_driver

[Samuel Thibault]

Okash Khawaja, on dim. 25 juin 2017 10:21:26 +0100, wrote:
> Third one is interesting. I haven't investigated it yet, but it seems to
> throw a kernel oops from tty_ldisc_reinit.

So it's probably some missing cleanups in the speakup code, which just
needs fixing :)

> We can avoid 2 and 3 above by calling tty_open_by_driver only when
> speakup is built into kernel and not when loaded as module.

That looks odd to me :)

Samuel

Re: unaddressed issues around tty_open_by_driver

[Okash Khawaja]

Hi,

On Tue, Jun 27, 2017 at 01:38:35AM +0200, Samuel Thibault wrote:
> Okash Khawaja, on dim. 25 juin 2017 10:21:26 +0100, wrote:
> > Third one is interesting. I haven't investigated it yet, but it seems to
> > throw a kernel oops from tty_ldisc_reinit.
> 
> So it's probably some missing cleanups in the speakup code, which just
> needs fixing :)
Yes, there are a couple of things. The kernel oops comes from ldisc.
Because we call tty_ldisc_release on module exit but don't set
tty->ldiscs[N_SPEAKUP] to NULL, the next time that tty is opened, it
tries to use N_SPEAKUP ldisc whose memory was released in
tty_ldisc_release. Calling tty_ldisc_unregister resolves it by setting
tty->ldiscs[N_SPEAKUP] to NULL.

Next, I think, we need to restore tty->termios.c_line to the ldisc
before speakup was loaded, because that's what is used when opening tty
[1]. Locally, I have done that by caching original ldisc and then
calling tty_set_termios_ldisc on module exit which resolves that issue.
However, in kernel tty_set_termios_ldisc is static function and will
need to be exported if we want to call it.

Finally, there is tty->count mismatch. On module exit, we don't
decrement tty->count which was incremented by tty_open_by_driver. I
don't know yet how to fix that.

So in summary, we need above changes, and also the flags to prevent
contention between user and kernel space.

> 
> > We can avoid 2 and 3 above by calling tty_open_by_driver only when
> > speakup is built into kernel and not when loaded as module.
> 
> That looks odd to me :)
Yes it does :) Not very familiar with kernel side use cases yet. My
thinking was to use different way of acquiring tty_struct when loaded as
module, because then we will have the device file. Probably not very
elegant.

Thanks,
Okash

[1]
http://elixir.free-electrons.com/linux/latest/source/drivers/tty/tty_io.c#L1484

Re: unaddressed issues around tty_open_by_driver

[Samuel Thibault]

Okash Khawaja, on mar. 27 juin 2017 10:44:45 +0100, wrote:
> Next, I think, we need to restore tty->termios.c_line to the ldisc
> before speakup was loaded, because that's what is used when opening tty
> [1]. Locally, I have done that by caching original ldisc and then
> calling tty_set_termios_ldisc on module exit which resolves that issue.
> However, in kernel tty_set_termios_ldisc is static function and will
> need to be exported if we want to call it.

Mmm, it looks odd to be doing such kind of hackery. It'd probably be
good to check how other line disciplines are doing.

Samuel

Re: unaddressed issues around tty_open_by_driver

[Okash Khawaja]

On Tue, Jun 27, 2017 at 11:50:18AM +0200, Samuel Thibault wrote:
> Okash Khawaja, on mar. 27 juin 2017 10:44:45 +0100, wrote:
> > Next, I think, we need to restore tty->termios.c_line to the ldisc
> > before speakup was loaded, because that's what is used when opening tty
> > [1]. Locally, I have done that by caching original ldisc and then
> > calling tty_set_termios_ldisc on module exit which resolves that issue.
> > However, in kernel tty_set_termios_ldisc is static function and will
> > need to be exported if we want to call it.
> 
> Mmm, it looks odd to be doing such kind of hackery. It'd probably be
> good to check how other line disciplines are doing.
Other ldiscs don't call tty_set_ldisc. They seem to rely on user space
setting the ldisc and hence to clean up also. They just register ldisc
on module init and unregister it on module exit.

I haven't looked at _exactly_ happens when something like N_MOUSE is
removed, so will do that now.

Re: unaddressed issues around tty_open_by_driver

[Samuel Thibault]

Okash Khawaja, on mar. 27 juin 2017 11:20:34 +0100, wrote:
> On Tue, Jun 27, 2017 at 11:50:18AM +0200, Samuel Thibault wrote:
> > Okash Khawaja, on mar. 27 juin 2017 10:44:45 +0100, wrote:
> > > Next, I think, we need to restore tty->termios.c_line to the ldisc
> > > before speakup was loaded, because that's what is used when opening tty
> > > [1]. Locally, I have done that by caching original ldisc and then
> > > calling tty_set_termios_ldisc on module exit which resolves that issue.
> > > However, in kernel tty_set_termios_ldisc is static function and will
> > > need to be exported if we want to call it.
> > 
> > Mmm, it looks odd to be doing such kind of hackery. It'd probably be
> > good to check how other line disciplines are doing.
> Other ldiscs don't call tty_set_ldisc. They seem to rely on user space
> setting the ldisc and hence to clean up also. They just register ldisc
> on module init and unregister it on module exit.

Ah, right. So we need to do what the unregistration triggered by
userland achieves, ok.

So yes, it could make sense to have to unstaticify some functions.

Samuel

Re: unaddressed issues around tty_open_by_driver

[Okash Khawaja]

Hi,

On Tue, Jun 27, 2017 at 12:27:14PM +0200, Samuel Thibault wrote:
> Okash Khawaja, on mar. 27 juin 2017 11:20:34 +0100, wrote:
> > On Tue, Jun 27, 2017 at 11:50:18AM +0200, Samuel Thibault wrote:
> > > Okash Khawaja, on mar. 27 juin 2017 10:44:45 +0100, wrote:
> > > > Next, I think, we need to restore tty->termios.c_line to the ldisc
> > > > before speakup was loaded, because that's what is used when opening tty
> > > > [1]. Locally, I have done that by caching original ldisc and then
> > > > calling tty_set_termios_ldisc on module exit which resolves that issue.
> > > > However, in kernel tty_set_termios_ldisc is static function and will
> > > > need to be exported if we want to call it.
> > > 
> > > Mmm, it looks odd to be doing such kind of hackery. It'd probably be
> > > good to check how other line disciplines are doing.
> > Other ldiscs don't call tty_set_ldisc. They seem to rely on user space
> > setting the ldisc and hence to clean up also. They just register ldisc
> > on module init and unregister it on module exit.
> 
> Ah, right. So we need to do what the unregistration triggered by
> userland achieves, ok.
> 
> So yes, it could make sense to have to unstaticify some functions.
> 

Regarding tty->count mismatch, it seems like several things depend on
tty->count and manipulating it won't be straightforward. More generally,
existing code to open and close tty is designed to be triggered from user
space. I think some of the problems mentioned above are there because we
are trying to overlaod existing user space oriented code with kernel
space.

Rather than dealing with subtleties of changing this code to allow
kernel access to tty, I suggest we create a separate kernel api which is
clean and simple. That way, we also avoid increasing complexity of
existing code. Here are broad lines of what I am suggesting.

Two functions:

struct tty_struct *tty_kopen(dev_t device);
void tty_kclose(struct tty_struct *tty, int idx);

And a tty->flag:

TTY_KOPENED to indicate that this tty_struct is in use by kernel.

tty_kopen will be a subset of tty_open_by_driver that we currently use
to open tty from kernel, i.e. it will only take the path that is valid
for opening from kernel. It will also check for and set TTY_KOPENED
flag.

tty_kclose will be similar to tty_release_struct. It will clear
TTY_KOPENED flag.

tty_open method in tty_io.c will check for TTY_KOPENED and return
-EBUSY if it is set.

So the idea is to make kopen of tty exclusive and protect that
exclusivity with TTY_KOPENED flag. That way we don't have to worry about
complexities, races etc of the regular user-space oriented tty code.

Thanks,
Okash

Re: unaddressed issues around tty_open_by_driver

[Okash Khawaja]

On Wed, Jun 28, 2017 at 09:51:55AM +0100, Okash Khawaja wrote:
> So the idea is to make kopen of tty exclusive and protect that
> exclusivity with TTY_KOPENED flag. That way we don't have to worry about
> complexities, races etc of the regular user-space oriented tty code.

Here's what I mean. I've done some rudimentary testing. It seems to
clean up alright, allowing ttyUSB0 or ttyS0 to be reused by user space
programs. It also prevents user program from using the tty held by
speakup while speakup is loaded.

We don't need tty_kclose though because we can instead call
tty_release_struct which will free up the tty, removing the need to
clear TTY_KOPENED flag.

---
 drivers/staging/speakup/spk_ttyio.c |    6 ++-
 drivers/tty/tty_io.c                |   56 ++++++++++++++++++++++++++++++++++--
 include/linux/tty.h                 |    7 +---
 3 files changed, 61 insertions(+), 8 deletions(-)

--- a/drivers/staging/speakup/spk_ttyio.c
+++ b/drivers/staging/speakup/spk_ttyio.c
@@ -164,7 +164,7 @@ static int spk_ttyio_initialise_ldisc(st
 	if (ret)
 		return ret;
 
-	tty = tty_open_by_driver(dev, NULL, NULL);
+	tty = tty_kopen(dev);
 	if (IS_ERR(tty))
 		return PTR_ERR(tty);
 
@@ -300,7 +300,9 @@ void spk_ttyio_release(void)
 
 	tty_ldisc_flush(speakup_tty);
 	tty_unlock(speakup_tty);
-	tty_ldisc_release(speakup_tty);
+	tty_release_struct(speakup_tty, speakup_tty->index);
+	if (tty_unregister_ldisc(N_SPEAKUP))
+		pr_warn("speakup: failed to unregister line discipline N_SPEAKUP\n");
 }
 EXPORT_SYMBOL_GPL(spk_ttyio_release);
 
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1786,6 +1786,53 @@ static struct tty_driver *tty_lookup_dri
 }
 
 /**
+ *	tty_kopen	-	open a tty device for kernel
+ *	@device: dev_t of device to open
+ *
+ *	Opens tty exclusively for kernel. Performs the driver lookup,
+ *	makes sure it's not already opened and performs the first-time
+ *	tty initialization.
+ *
+ *	Returns the locked initialized &tty_struct
+ *
+ *	Claims the global tty_mutex to serialize:
+ *	  - concurrent first-time tty initialization
+ *	  - concurrent tty driver removal w/ lookup
+ *	  - concurrent tty removal from driver table
+ */
+struct tty_struct *tty_kopen(dev_t device)
+{
+        struct tty_struct *tty;
+        struct tty_driver *driver = NULL;
+        int index = -1;
+
+        mutex_lock(&tty_mutex);
+        driver = tty_lookup_driver(device, NULL, &index);
+        if (IS_ERR(driver)) {
+                mutex_unlock(&tty_mutex);
+                return ERR_CAST(driver);
+        }
+
+        /* check whether we're reopening an existing tty */
+        tty = tty_driver_lookup_tty(driver, NULL, index);
+        if (IS_ERR(tty))
+                goto out;
+
+        if (tty) {
+                tty_kref_put(tty);  /* drop kref from tty_driver_lookup_tty() */
+                tty = ERR_PTR(-EBUSY);
+        } else { /* Returns with the tty_lock held for now */
+                tty = tty_init_dev(driver, index);
+                set_bit(TTY_KOPENED, &tty->flags);
+        }
+out:
+        mutex_unlock(&tty_mutex);
+        tty_driver_kref_put(driver);
+        return tty;
+}
+EXPORT_SYMBOL(tty_kopen);
+
+/**
  *	tty_open_by_driver	-	open a tty device
  *	@device: dev_t of device to open
  *	@inode: inode of device file
@@ -1801,7 +1848,7 @@ static struct tty_driver *tty_lookup_dri
  *	  - concurrent tty driver removal w/ lookup
  *	  - concurrent tty removal from driver table
  */
-struct tty_struct *tty_open_by_driver(dev_t device, struct inode *inode,
+static struct tty_struct *tty_open_by_driver(dev_t device, struct inode *inode,
 					     struct file *filp)
 {
 	struct tty_struct *tty;
@@ -1824,6 +1871,12 @@ struct tty_struct *tty_open_by_driver(de
 	}
 
 	if (tty) {
+		if (test_bit(TTY_KOPENED, &tty->flags)) {
+			tty_kref_put(tty);
+			mutex_unlock(&tty_mutex);
+			tty = ERR_PTR(-EBUSY);
+			goto out;
+		}
 		mutex_unlock(&tty_mutex);
 		retval = tty_lock_interruptible(tty);
 		tty_kref_put(tty);  /* drop kref from tty_driver_lookup_tty() */
@@ -1846,7 +1899,6 @@ out:
 	tty_driver_kref_put(driver);
 	return tty;
 }
-EXPORT_SYMBOL_GPL(tty_open_by_driver);
 
 /**
  *	tty_open		-	open a tty device
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -362,6 +362,7 @@ struct tty_file_private {
 #define TTY_NO_WRITE_SPLIT 	17	/* Preserve write boundaries to driver */
 #define TTY_HUPPED 		18	/* Post driver->hangup() */
 #define TTY_LDISC_HALTED	22	/* Line discipline is halted */
+#define TTY_KOPENED             23      /* TTY exclusively opened by kernel */
 
 /* Values for tty->flow_change */
 #define TTY_THROTTLE_SAFE 1
@@ -399,8 +400,7 @@ extern struct tty_struct *get_current_tt
 /* tty_io.c */
 extern int __init tty_init(void);
 extern const char *tty_name(const struct tty_struct *tty);
-extern struct tty_struct *tty_open_by_driver(dev_t device, struct inode *inode,
-		struct file *filp);
+extern struct tty_struct *tty_kopen(dev_t device);
 extern int tty_dev_name_to_number(const char *name, dev_t *number);
 #else
 static inline void tty_kref_put(struct tty_struct *tty)
@@ -422,8 +422,7 @@ static inline int __init tty_init(void)
 { return 0; }
 static inline const char *tty_name(const struct tty_struct *tty)
 { return "(none)"; }
-static inline struct tty_struct *tty_open_by_driver(dev_t device,
-		struct inode *inode, struct file *filp)
+static inline struct tty_struct *tty_kopen(dev_t device)
 { return NULL; }
 static inline int tty_dev_name_to_number(const char *name, dev_t *number)
 { return -ENOTSUPP; }

Re: unaddressed issues around tty_open_by_driver

[Okash Khawaja]

On Wed, Jun 28, 2017 at 09:27:56PM +0100, Okash Khawaja wrote:
> Here's what I mean. I've done some rudimentary testing. It seems to
> clean up alright, allowing ttyUSB0 or ttyS0 to be reused by user space
> programs. It also prevents user program from using the tty held by
> speakup while speakup is loaded.
> 
> We don't need tty_kclose though because we can instead call
> tty_release_struct which will free up the tty, removing the need to
> clear TTY_KOPENED flag.
Thinking of raising this on wider mailing list - basically same that we
submitted the patch for exporting tty_open_by_driver to. If that makes
sense.

Thanks,
Okash