Re: [PATCH v2 3/8] s390/vfio-ap: Fix use of wrong lock in mdev probe function

Anthony Krowiak <[email protected]>
Newsgroups org.kernel.vger.stable,org.kernel.vger.kvm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-s390
Message-ID <[email protected]>

On 8/11/26 11:58 AM, Matthew Rosato wrote:
> On 8/10/26 3:22 PM, Anthony Krowiak wrote:
>> The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock
>> mutex to guard the add of a newly created ap_matrix_mdev object to the
>> matrix_dev->mdev_list. This mutex does not protect against traversal
>> of the list; its purpose is to guard against concurrent access to fields
>> contained in an ap_matrix_mdev object. This could lead to kernel memory
>> corruption or use-after-free if another mdev is created concurrently.
>>
>> The adding of an ap_matrix_mdev object to matrix_dev->mdev_list
>> is now guarded by the matrix_dev->guests_lock which is the correct
>> way to protect against concurrent mdev_list access.
>>
>> See the vfio-ap-locking.rst in the linux kernel tree.
>>
>> Fixes: 2c1ee8983aa3 ("s390/vfio-ap: prepare for dynamic update of guest's APCB on queue probe/remove")
>> Cc: [email protected]
>> Signed-off-by: Anthony Krowiak <[email protected]>
>> ---
>>   drivers/s390/crypto/vfio_ap_ops.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
>> index e382e5a1cb99..a472de00bc14 100644
>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>> @@ -803,9 +803,9 @@ static int vfio_ap_mdev_probe(struct mdev_device *mdev)
>>   	matrix_mdev->req_trigger = NULL;
>>   	matrix_mdev->cfg_chg_trigger = NULL;
>>   	dev_set_drvdata(&mdev->dev, matrix_mdev);
>> -	mutex_lock(&matrix_dev->mdevs_lock);
>> +	mutex_lock(&matrix_dev->guests_lock);
> Sashiko reports that this patch introduces a regression, which seems valid.
>
> AFAICT you resolve this regression with patch 7 of this series.
>
> For the sake of bisect, can you look at whether squashing these 2
> patches together would work so that we don't have an interim regression?

The reason for the two different patches is because the shah on the 
Fixes: tag
differ.

>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.