Re: tty contention resulting from tty_open_by_device export

[Okash Khawaja <okash.khawaja@gmail.com>]

On Sat, Jul 08, 2017 at 10:38:03AM +0200, Greg Kroah-Hartman wrote:

> > +
> > +        if (tty) {
> > +                tty_kref_put(tty);  /* drop kref from tty_driver_lookup_tty() */
> 
> Put the comment above the line?
> 
Sure

> > +                tty = ERR_PTR(-EBUSY);
> > +        } else { /* Returns with the tty_lock held for now */
> 
> I don't understand this comment.
> 
This is same comment in tty_open_by_driver. Basically, tty_init_dev
returns tty locked so that it doesn't dissapear from underneath the
caller. I am not sure about the "for now" part of the comment. I'll
remove it.

> > +                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);
> 
> EXPORT_SYMBOL_GPL()?  :)
> 
Of course, will update
> >  /**
> >   *	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 */
> 
> Minor nit, please use tabs here.
> 
Will do

> Overall, the idea looks sane to me.  Keeping userspace from opening a
> tty that the kernel has opened internally makes sense, hopefully
> userspace doesn't get too confused when that happens.  I don't think we
> normally return -EBUSY from an open call, have you seen what happens
> with apps when you do this (like minicom?)
> 
Yes, returning -EBUSY is a change in the interface. I will test against
applications like minicom before resubmitting this.

Thanks,
Okash