On 2/10/23 12:42 PM, Eric Farman wrote:
> The logic in vfio_ccw_sch_shutdown() always assumed that the input
> subchannel would point to a vfio_ccw_private struct, without checking
> that one exists. The blamed commit put in a check for this scenario,
> to prevent the possibility of a missing private.
>
> The trouble is that check was put alongside a WARN_ON(), presuming
> that such a scenario would be a cause for concern. But this can be
> triggered by binding a subchannel to vfio-ccw, and rebooting the
> system before starting the mdev (via "mdevctl start" or similar)
> or after stopping it. In those cases, shutdown doesn't need to
> worry because either the private was never allocated, or it was
> cleaned up by vfio_ccw_mdev_remove().
>
> Remove the WARN_ON() piece of this check, since there are plausible
> scenarios where private would be NULL in this path.
>
> Fixes: 9e6f07cd1eaa ("vfio/ccw: create a parent struct")
> Signed-off-by: Eric Farman <farman@xxxxxxxxxxxxx>
Reviewed-by: Matthew Rosato <mjrosato@xxxxxxxxxxxxx>
The other ops in vfio_ccw_sch_driver look OK in that they quietly tolerate this scenario -- with .irq being an exception but the rationale and what we log there makes sense to me (we shouldn't get an interrupt on a disabled subchannel) plus it's only a debug log not a WARN.
