[Devel] [RFC rh7 v2] ve/tty: vt -- Implement per VE support for virtual consoles

Cyrill Gorcunov gorcunov at virtuozzo.com
Fri Jul 31 07:09:40 PDT 2015


On Fri, Jul 31, 2015 at 04:22:58PM +0300, Vladimir Davydov wrote:
> > 
> >    Thus we need somehow to be sure that at least
> >    masters map is consistent when lookup is called
> >    (once ttys are queued for release they carry
> >     "exiting" bits).
> 
> Sorry, but it's really difficult to understand what you mean here. Could
> you please write it more technically, I mean:
> 
> CPU0		CPU1
> ----		----
> BLAH
> 		BLAH-BLAH
> OUCH

Scenario: only master has been opened.

CPU0 (master peer)			CPU1 (slave peer)
---- 					----
tty_release
 release_tty
  shutdown
  tty_kref_put (for slave peer)
					queue_release_one_tty
					   tty->cleanup
					 free_tty_struct(tty);
  tty_kref_put
   queue_release_one_tty
   ...
   here tty->link points to freed
   structure, and tty map carries
   freed tty for slave (that's why
   i check for master to be alive
   in lookup when slave is searched)

All this dances are to insure that we can use slave
peer when lookup is happened right after the tty
file release but structures are in process of
freeing.

You know, I think I can get rid of it and rely solely on
master tty map: remove is always will be called for
it and we might use tty->link to examine the slave
peer.

> > 
> >    Once I introduce order in cleanup() routine
> >    I can be sure that
> 
> Anyway, your solution is unacceptable AFAICS, because you make one work
> wait for another, which will lead to a dead lock if they both get queued
> to the same worker.

Hmm. Letme re-check. Thanks!



More information about the Devel mailing list