tree a4dbaadf652c32716f3e7583d260cca6c045ffed
parent 63b66a5147069bda815989732442cb07790609db
author Jordan Niethe <jniethe5@gmail.com> 1693267921 +1000
committer Alexey Kardashevskiy <aik@ozlabs.ru> 1695025245 +1000

virtio-serial: Do not close stdout on quiesce

Commit 76fee95 ("slof: Only close stdout for virtio-serial devices")
says that commit cf28264 ("virtio-serial: Rework shutdown sequence")
fixed a hang. The problem was believed to be that it was necessary to
close stdout to shutdown the underlying virtio device.

Commit cf28264 ("virtio-serial: Rework shutdown sequence") closed stdout
on quiesce. This meant when prom_init() called write on stdout after
quiesce, there is a use after free so this is unreliable, and can also
hang (especially after reboots).

Quiescing is intended to put hardware into a safe state for the client
to take over. It is incorrect for SLOF to close ihandles that the client
could still be using, even after a quiesce.

Rather than closing the stdout device, all that needs to happen is to
ensure virtio-serial-shutdown gets called. On quiesce, close the virtio
device, but leave the stdout device itself open.

Commit 8174acd ("virtio-serial: Close device completely") handles reads
and writes as no-ops if the underlying virtio device is closed so there
is no problem with the client calling "write" on stdout after this, but
no output will be displayed.

Fixes: cf28264 ("virtio-serial: Rework shutdown sequence")
Debugged-by: Kautuk Consul <kconsul@linux.vnet.ibm.com>
Co-developed-by: Kautuk Consul <kconsul@linux.vnet.ibm.com>
Signed-off-by: Kautuk Consul <kconsul@linux.vnet.ibm.com>
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>