From: Tony Krowiak <akrowiak@linux.ibm.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
borntraeger@de.ibm.com, cohuck@redhat.com,
pasic@linux.vnet.ibm.com, jjherne@linux.ibm.com, jgg@nvidia.com,
alex.williamson@redhat.com, kwankhede@nvidia.com,
frankja@linux.ibm.com, david@redhat.com, imbrenda@linux.ibm.com,
hca@linux.ibm.com
Subject: Re: [PATCH v4 1/2] s390/vfio-ap: fix memory leak in mdev remove callback
Date: Wed, 26 May 2021 08:37:59 -0400 [thread overview]
Message-ID: <1eda14a0-fdcb-0d47-b1ed-1a1f5847efe8@linux.ibm.com> (raw)
In-Reply-To: <20210525150337.021aabd8.pasic@linux.ibm.com>
On 5/25/21 9:03 AM, Halil Pasic wrote:
> On Fri, 21 May 2021 15:36:47 -0400
> Tony Krowiak <akrowiak@linux.ibm.com> wrote:
>
>> The mdev remove callback for the vfio_ap device driver bails out with
>> -EBUSY if the mdev is in use by a KVM guest. The intended purpose was
>> to prevent the mdev from being removed while in use; however, returning a
>> non-zero rc does not prevent removal. This could result in a memory leak
>> of the resources allocated when the mdev was created. In addition, the
>> KVM guest will still have access to the AP devices assigned to the mdev
>> even though the mdev no longer exists.
>>
>> To prevent this scenario, cleanup will be done - including unplugging the
>> AP adapters, domains and control domains - regardless of whether the mdev
>> is in use by a KVM guest or not.
>>
>> Fixes: 258287c994de ("s390: vfio-ap: implement mediated device open callback")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
>> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> AFAIU we all agree that, after patch there is a possibility for an use
> after free error. I'm a little confused by the fact that we want this
> one for stable, but the patch that fixes the use after free as no
> Cc stable (it can't have a proper fixes tag, because this one is not yet
> merged). Actually I'm not a big fan of splitting up patches to the
> extent that when not all patches of the series are applied we get bugous
> behavior (e.g. patch n breaks something that is live at patch n level,
> but it is supposed to be OK, because patch n+m is going to fix it (where
> n,m \in \Z^{+}).
After thinking about this some more, this patch does not really
fix a memory leak and should probably not be flagged as a fix
for 258287c994. Memory is not leaked
because the remove callback returns -EBUSY without freeing
mdev storage or resetting the queues.
Under normal circumstances, if the mdev is removed before
the mdev fd is closed (i.e., the guest is shut down), the process
will wait until the fd is closed, at which time the
release callback will get invoked. Since the release callback
clears the KVM pointer from the matrix_mdev, the remove
callback will not return -EBUSY and will in fact free the mdev
storage when it is subsequently invoked.
I am going to change the subject and remove the 'Fixes'
tag as well as the 'Cc' of stable. I'll change the subject to
something like:
"s390/vfio-ap: always free storage for mdev in remove callback"
>
> Do we want to squash these? Is the use after free possible prior to this
> patch?
>
> Regards,
> Halil
next prev parent reply other threads:[~2021-05-26 12:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 19:36 [PATCH v4 0/2] s390/vfio-ap: fix memory leak in mdev remove callback Tony Krowiak
2021-05-21 19:36 ` [PATCH v4 1/2] " Tony Krowiak
2021-05-25 13:03 ` Halil Pasic
2021-05-25 13:22 ` Tony Krowiak
2021-05-26 12:37 ` Tony Krowiak [this message]
2021-05-21 19:36 ` [PATCH v4 2/2] s390/vfio-ap: control access to PQAP(AQIC) interception handler Tony Krowiak
2021-05-23 22:57 ` Jason Gunthorpe
2021-05-25 14:59 ` Tony Krowiak
2021-05-25 15:00 ` Jason Gunthorpe
2021-05-24 14:37 ` Jason J. Herne
2021-05-25 13:16 ` Tony Krowiak
2021-05-25 13:19 ` Jason Gunthorpe
2021-05-25 15:08 ` Tony Krowiak
2021-05-25 15:11 ` Jason Gunthorpe
2021-05-25 15:56 ` Tony Krowiak
2021-05-25 16:29 ` Jason Gunthorpe
2021-05-27 2:28 ` Tony Krowiak
2021-05-27 11:24 ` Jason Gunthorpe
2021-05-25 13:24 ` Jason J. Herne
2021-05-25 13:26 ` Jason Gunthorpe
2021-05-25 14:07 ` Jason J. Herne
2021-05-25 14:16 ` Jason Gunthorpe
2021-06-14 7:51 ` [PATCH v4 0/2] s390/vfio-ap: fix memory leak in mdev remove callback Christian Borntraeger
2021-06-16 14:24 ` Tony Krowiak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1eda14a0-fdcb-0d47-b1ed-1a1f5847efe8@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=jgg@nvidia.com \
--cc=jjherne@linux.ibm.com \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.ibm.com \
--cc=pasic@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox