[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