All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Halil Pasic <pasic@linux.ibm.com>, Tony Krowiak <akrowiak@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, cohuck@redhat.com,
	alex.williamson@redhat.com, kwankhede@nvidia.com,
	david@redhat.com
Subject: Re: [PATCH] s390/vfio-ap: Clean up vfio_ap resources when KVM pointer invalidated
Date: Mon, 7 Dec 2020 16:42:05 +0100	[thread overview]
Message-ID: <d0c2aaee-3367-a15d-514d-88211251ca06@de.ibm.com> (raw)
In-Reply-To: <20201207162411.050c6cea.pasic@linux.ibm.com>



On 07.12.20 16:24, Halil Pasic wrote:
> On Fri, 4 Dec 2020 11:48:24 -0500
> Tony Krowiak <akrowiak@linux.ibm.com> wrote:
> 
>> On 12/3/20 12:55 PM, Halil Pasic wrote:
>>> On Wed,  2 Dec 2020 18:41:01 -0500
>>> Tony Krowiak <akrowiak@linux.ibm.com> wrote:
>>>  
>>>> The vfio_ap device driver registers a group notifier with VFIO when the
>>>> file descriptor for a VFIO mediated device for a KVM guest is opened to
>>>> receive notification that the KVM pointer is set (VFIO_GROUP_NOTIFY_SET_KVM
>>>> event). When the KVM pointer is set, the vfio_ap driver stashes the pointer
>>>> and calls the kvm_get_kvm() function to increment its reference counter.
>>>> When the notifier is called to make notification that the KVM pointer has
>>>> been set to NULL, the driver should clean up any resources associated with
>>>> the KVM pointer and decrement its reference counter. The current
>>>> implementation does not take care of this clean up.
>>>>
>>>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>  
>>> Do we need a Fixes tag? Do we need this backported? In my opinion
>>> this is necessary since the interrupt patches.  
>>
>> I'll put in a fixes tag:
>> Fixes: 258287c994de (s390: vfio-ap: implement mediated device open callback)
>>
>> Yes, this should probably be backported.
> 
> I changed my mind regarding the severity of this issue. I was paranoid
> about post-mortem interrupts, and resulting notifier byte updates by the
> machine. What I overlooked is that the pin is going to prevent the memory
> form getting repurposed. I.e. if we have something like vmalloc(),
> vfio_pin(notifier_page), vfree(), I believe the notifier_page is not free
> (available for allocation). So the worst case scenario is IMHO a resource
> leak and not corruption. So I'm not sure this must be backported.
> Opinions?

Resource leaks qualify for backport and cc stable, but it is not a security
issue so this has no urgency and CVE and these kind of things.

So lets finish this without hurry, add cc stable and then look for necessary
distro backports.

  reply	other threads:[~2020-12-07 15:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-02 23:41 [PATCH] s390/vfio-ap: Clean up vfio_ap resources when KVM pointer invalidated Tony Krowiak
2020-12-03 10:19 ` Cornelia Huck
2020-12-03 17:01   ` Halil Pasic
2020-12-03 19:14     ` Tony Krowiak
2020-12-03 17:55 ` Halil Pasic
2020-12-04 14:43   ` Tony Krowiak
2020-12-04 19:05     ` Halil Pasic
2020-12-04 19:46       ` Tony Krowiak
2020-12-04 21:54         ` Halil Pasic
2020-12-07 18:50       ` Tony Krowiak
2020-12-08  0:01         ` Halil Pasic
     [not found]           ` <e196b743-74d8-398b-4b3e-4a64002d9bfc@linux.ibm.com>
2020-12-13 22:57             ` Halil Pasic
2020-12-04 16:48   ` Tony Krowiak
2020-12-04 16:57     ` Cornelia Huck
2020-12-04 19:47       ` Tony Krowiak
2020-12-07 15:24     ` Halil Pasic
2020-12-07 15:42       ` Christian Borntraeger [this message]
2020-12-07 19:05 ` Tony Krowiak
2020-12-08  0:40   ` Halil Pasic
2020-12-11 21:08     ` Tony Krowiak
2020-12-13 23:13       ` Halil Pasic

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=d0c2aaee-3367-a15d-514d-88211251ca06@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pasic@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.