On Thu, 22 Oct 2020 13:11:59 -0400 Tony Krowiak <akrowiak@xxxxxxxxxxxxx> wrote: > Introduces a new driver callback to prevent a root user from unbinding > an AP queue from its device driver if the queue is in use. The callback > will be invoked whenever a change to the AP bus's sysfs apmask or aqmask > attributes would result in one or more AP queues being removed from its > driver. If the callback responds in the affirmative for any driver > queried, the change to the apmask or aqmask will be rejected with a device > in use error. Like discussed last time, there seems to be nothing, that would prevent a resource becoming in use between the in_use() callback returned false and the resource being removed as a result of ap_bus_revise_bindings(). Another thing that may be of interest, is that now we hold the ap_perms_mutex for the in_use() checks. The ap_perms_mutex is used in ap_device_probe() and I don't quite understand some usages of in zcrypt_api.c My feeling is that the extra pressure on that lock should not be a problem, except if in_use() were to not return because of some deadlock. With all that said if Harald is fine with it, so am I. Acked-by: Halil Pasic <pasic@xxxxxxxxxxxxx> > > For this patch, only non-default drivers will be queried. Currently, > there is only one non-default driver, the vfio_ap device driver. The > vfio_ap device driver facilitates pass-through of an AP queue to a > guest. The idea here is that a guest may be administered by a different > sysadmin than the host and we don't want AP resources to unexpectedly > disappear from a guest's AP configuration (i.e., adapters and domains > assigned to the matrix mdev). This will enforce the proper procedure for > removing AP resources intended for guest usage which is to > first unassign them from the matrix mdev, then unbind them from the > vfio_ap device driver. > > Signed-off-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx> >
