[Meego-kernel] [PATCH] Modem trace capture solution for mobile platforms.
alan at linux.intel.com
Tue Oct 19 12:41:49 PDT 2010
> I did this to address the comment that n_tracerouter should only be
> allowed to sit on one tty port per SW entity and to prevent a
> multiple tty port opening. If it's okay to loose this check, does
> this 2nd revision address the concern of having only one tty port
> opening that this ldisc sits on?
You have a global "this_tty", that check won't help give then tty->
will be different for each tty device.
Now you probably do want to check if (this_tty != NULL) ?
> My thinking was if we are exiting, the system is shutting down, and if
> there is mutex, I don't want it to hold up system shutdown. I can
> remove this block if this is a problem.
It's not safe - you need to wait for the mutex to be released.
> >> + this_tty = tty_kref_get(tty);
> > You still have the problem with not preventing two users (or
> > handling it)
> That goes back to the question I raised earlier. How do you suggest
> I go about handling this?
In the open method
if (this_tty != NULL)
this_tty = tty_kref_get(tty);
> >> + mutex_lock(&writelock);
> >> +
> >> + if ((cp != NULL) && (count > 0) && (this_tty != NULL))
> >> + this_tty->ops->write(this_tty, cp, count);
> > And this_tty could go to NULL during that if the tty is being
> > closed or hung up...
> Wouldn't the close() have to wait if the mutex_lock() has locked this
> section? then once close() does happen, this_tty is set to NULL which
Sorry you are right - your close does take the lock
More information about the Meego-kernel