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

[Cyrill Gorcunov]

On 07/31/2015 02:48 PM, Cyrill Gorcunov wrote:
...
>>>
>>> IOW, slave peer may be cleaned up via two cases: via
>>> explicit release on file close (if it has been opened),
>>> or via kref-put (if it has not been opened, but master
>>> slave is closing decrementing slave peer's kref and
>>> kernel schedule to call cleanup() on both peers but
>>> cleanup() routine can be called in any order, the
>>> kernel chooses on its own which one to clean first).
>>
>> All your cleanup consists of tty_port_put. Why is it bad to call
>> tty_port_put for master before tty_port_put for slave? Both ttys are
>> already dead, so why should we care?
> 
> This is not about tty_port_put, we have to be sure that cleanup
> for slave is finished _before_ the master. Wait please, I'll reply
> via another mail, because this is long.

Here are some details on why we have to wait that the master peer
should wait until slave peer is closed: every master device is
a hoster for slave tty structure, on any lookup either both
peers should be fully functional (or exiting) either none
of them should exist.

Whily there is no way to run lookup procedure in parralel
mode (it's under mutex) the cleanup routine may run in
arbitrary order, thus array map won't be consistent. But
this is half of a problem: we rely on tty->link to be
consistent as well and tty_io.c:release_one_tty frees
tty strucure pointer to which we still may carry in
master peer structure.

Now we have two scenarios:

1) Master peer opened and slave peer has been opened
   too.

   Here on both peers remove() helper will be called
   by tty layer, which would clean tty map entries,
   thus our lookup will give us back solid results

2) Master peer opened by slave peer is not, and now
   master is closing

   Here remove() helper is called for master slave,
   and tty map cleans the entry (the slave peer
   still is present inside map). Note when remove()
   starts it takes tty_mutex, so that lookup and
   remove can't run simultaneously but it queues
   to cleanup both peers (master and slave) and
   cleanup() itself may be called for slave first
   and for master at second, ie in reverse order.

   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).

   Once I introduce order in cleanup() routine
   I can be sure that

   a) master map always carries valid pointer,
      it's either empty (if no peer exists and
      we have to allocate new ones) either the
      pointer is valid and can be tested for
      "alive" state

   b) slave map may point to tty which is being
      freed, thus before before anything else
      we need to test if master peer is not
      existing

Something like that. If you see some better
idea how to carry consistency with tty pairs
please letme know.