From: Marc Zyngier <maz@kernel.org>
To: Zenghui Yu <yuzenghui@huawei.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 2/2] KVM: arm64: vgic-its: Fix memory leak on the error path of vgic_add_lpi()
Date: Thu, 16 Apr 2020 18:23:44 +0100 [thread overview]
Message-ID: <2173e13527cc9578838f0364ad29f6cc@kernel.org> (raw)
In-Reply-To: <610f2195-f85d-4beb-b711-47d63bb393d0@huawei.com>
On 2020-04-16 02:17, Zenghui Yu wrote:
> On 2020/4/14 11:03, Zenghui Yu wrote:
>> If we're going to fail out the vgic_add_lpi(), let's make sure the
>> allocated vgic_irq memory is also freed. Though it seems that both
>> cases are unlikely to fail.
>>
>> Cc: Zengruan Ye <yezengruan@huawei.com>
>> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
>> ---
>> virt/kvm/arm/vgic/vgic-its.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-its.c
>> b/virt/kvm/arm/vgic/vgic-its.c
>> index d53d34a33e35..3c3b6a0f2dce 100644
>> --- a/virt/kvm/arm/vgic/vgic-its.c
>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>> @@ -98,12 +98,16 @@ static struct vgic_irq *vgic_add_lpi(struct kvm
>> *kvm, u32 intid,
>> * the respective config data from memory here upon mapping the
>> LPI.
>> */
>> ret = update_lpi_config(kvm, irq, NULL, false);
>> - if (ret)
>> + if (ret) {
>> + kfree(irq);
>> return ERR_PTR(ret);
>> + }
>> ret = vgic_v3_lpi_sync_pending_status(kvm, irq);
>> - if (ret)
>> + if (ret) {
>> + kfree(irq);
>> return ERR_PTR(ret);
>> + }
>
> Looking at it again, I realized that this error handling is still not
> complete. Maybe we should use a vgic_put_irq() instead so that we can
> also properly delete the vgic_irq from lpi_list.
Yes, this is a more correct fix indeed. There is still a bit of a
bizarre
behaviour if you have two vgic_add_lpi() racing to create the same
interrupt,
which is pretty dodgy anyway (it means we have two MAPI at the same
time...).
You end-up with re-reading the state from memory... Oh well.
> Marc, what do you think? Could you please help to fix it, or I can
> resend it.
I've fixed it as such (with a comment for a good measure):
diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index 3c3b6a0f2dce..c012a52b19f5 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -96,16 +96,19 @@ static struct vgic_irq *vgic_add_lpi(struct kvm
*kvm, u32 intid,
* We "cache" the configuration table entries in our struct
vgic_irq's.
* However we only have those structs for mapped IRQs, so we read in
* the respective config data from memory here upon mapping the LPI.
+ *
+ * Should any of these fail, behave as if we couldn't create the LPI
+ * by dropping the refcount and returning the error.
*/
ret = update_lpi_config(kvm, irq, NULL, false);
if (ret) {
- kfree(irq);
+ vgic_put_irq(kvm, irq);
return ERR_PTR(ret);
}
ret = vgic_v3_lpi_sync_pending_status(kvm, irq);
if (ret) {
- kfree(irq);
+ vgic_put_irq(kvm, irq);
return ERR_PTR(ret);
}
Let me know if you agree with that.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Zenghui Yu <yuzenghui@huawei.com>
Cc: suzuki.poulose@arm.com, linux-kernel@vger.kernel.org,
yezengruan@huawei.com, james.morse@arm.com,
linux-arm-kernel@lists.infradead.org, wanghaibin.wang@huawei.com,
kvmarm@lists.cs.columbia.edu, julien.thierry.kdev@gmail.com
Subject: Re: [PATCH 2/2] KVM: arm64: vgic-its: Fix memory leak on the error path of vgic_add_lpi()
Date: Thu, 16 Apr 2020 18:23:44 +0100 [thread overview]
Message-ID: <2173e13527cc9578838f0364ad29f6cc@kernel.org> (raw)
In-Reply-To: <610f2195-f85d-4beb-b711-47d63bb393d0@huawei.com>
On 2020-04-16 02:17, Zenghui Yu wrote:
> On 2020/4/14 11:03, Zenghui Yu wrote:
>> If we're going to fail out the vgic_add_lpi(), let's make sure the
>> allocated vgic_irq memory is also freed. Though it seems that both
>> cases are unlikely to fail.
>>
>> Cc: Zengruan Ye <yezengruan@huawei.com>
>> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
>> ---
>> virt/kvm/arm/vgic/vgic-its.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-its.c
>> b/virt/kvm/arm/vgic/vgic-its.c
>> index d53d34a33e35..3c3b6a0f2dce 100644
>> --- a/virt/kvm/arm/vgic/vgic-its.c
>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>> @@ -98,12 +98,16 @@ static struct vgic_irq *vgic_add_lpi(struct kvm
>> *kvm, u32 intid,
>> * the respective config data from memory here upon mapping the
>> LPI.
>> */
>> ret = update_lpi_config(kvm, irq, NULL, false);
>> - if (ret)
>> + if (ret) {
>> + kfree(irq);
>> return ERR_PTR(ret);
>> + }
>> ret = vgic_v3_lpi_sync_pending_status(kvm, irq);
>> - if (ret)
>> + if (ret) {
>> + kfree(irq);
>> return ERR_PTR(ret);
>> + }
>
> Looking at it again, I realized that this error handling is still not
> complete. Maybe we should use a vgic_put_irq() instead so that we can
> also properly delete the vgic_irq from lpi_list.
Yes, this is a more correct fix indeed. There is still a bit of a
bizarre
behaviour if you have two vgic_add_lpi() racing to create the same
interrupt,
which is pretty dodgy anyway (it means we have two MAPI at the same
time...).
You end-up with re-reading the state from memory... Oh well.
> Marc, what do you think? Could you please help to fix it, or I can
> resend it.
I've fixed it as such (with a comment for a good measure):
diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index 3c3b6a0f2dce..c012a52b19f5 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -96,16 +96,19 @@ static struct vgic_irq *vgic_add_lpi(struct kvm
*kvm, u32 intid,
* We "cache" the configuration table entries in our struct
vgic_irq's.
* However we only have those structs for mapped IRQs, so we read in
* the respective config data from memory here upon mapping the LPI.
+ *
+ * Should any of these fail, behave as if we couldn't create the LPI
+ * by dropping the refcount and returning the error.
*/
ret = update_lpi_config(kvm, irq, NULL, false);
if (ret) {
- kfree(irq);
+ vgic_put_irq(kvm, irq);
return ERR_PTR(ret);
}
ret = vgic_v3_lpi_sync_pending_status(kvm, irq);
if (ret) {
- kfree(irq);
+ vgic_put_irq(kvm, irq);
return ERR_PTR(ret);
}
Let me know if you agree with that.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Zenghui Yu <yuzenghui@huawei.com>
Cc: kvmarm@lists.cs.columbia.edu, james.morse@arm.com,
julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com,
wanghaibin.wang@huawei.com, yezengruan@huawei.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: arm64: vgic-its: Fix memory leak on the error path of vgic_add_lpi()
Date: Thu, 16 Apr 2020 18:23:44 +0100 [thread overview]
Message-ID: <2173e13527cc9578838f0364ad29f6cc@kernel.org> (raw)
In-Reply-To: <610f2195-f85d-4beb-b711-47d63bb393d0@huawei.com>
On 2020-04-16 02:17, Zenghui Yu wrote:
> On 2020/4/14 11:03, Zenghui Yu wrote:
>> If we're going to fail out the vgic_add_lpi(), let's make sure the
>> allocated vgic_irq memory is also freed. Though it seems that both
>> cases are unlikely to fail.
>>
>> Cc: Zengruan Ye <yezengruan@huawei.com>
>> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
>> ---
>> virt/kvm/arm/vgic/vgic-its.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-its.c
>> b/virt/kvm/arm/vgic/vgic-its.c
>> index d53d34a33e35..3c3b6a0f2dce 100644
>> --- a/virt/kvm/arm/vgic/vgic-its.c
>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>> @@ -98,12 +98,16 @@ static struct vgic_irq *vgic_add_lpi(struct kvm
>> *kvm, u32 intid,
>> * the respective config data from memory here upon mapping the
>> LPI.
>> */
>> ret = update_lpi_config(kvm, irq, NULL, false);
>> - if (ret)
>> + if (ret) {
>> + kfree(irq);
>> return ERR_PTR(ret);
>> + }
>> ret = vgic_v3_lpi_sync_pending_status(kvm, irq);
>> - if (ret)
>> + if (ret) {
>> + kfree(irq);
>> return ERR_PTR(ret);
>> + }
>
> Looking at it again, I realized that this error handling is still not
> complete. Maybe we should use a vgic_put_irq() instead so that we can
> also properly delete the vgic_irq from lpi_list.
Yes, this is a more correct fix indeed. There is still a bit of a
bizarre
behaviour if you have two vgic_add_lpi() racing to create the same
interrupt,
which is pretty dodgy anyway (it means we have two MAPI at the same
time...).
You end-up with re-reading the state from memory... Oh well.
> Marc, what do you think? Could you please help to fix it, or I can
> resend it.
I've fixed it as such (with a comment for a good measure):
diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index 3c3b6a0f2dce..c012a52b19f5 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -96,16 +96,19 @@ static struct vgic_irq *vgic_add_lpi(struct kvm
*kvm, u32 intid,
* We "cache" the configuration table entries in our struct
vgic_irq's.
* However we only have those structs for mapped IRQs, so we read in
* the respective config data from memory here upon mapping the LPI.
+ *
+ * Should any of these fail, behave as if we couldn't create the LPI
+ * by dropping the refcount and returning the error.
*/
ret = update_lpi_config(kvm, irq, NULL, false);
if (ret) {
- kfree(irq);
+ vgic_put_irq(kvm, irq);
return ERR_PTR(ret);
}
ret = vgic_v3_lpi_sync_pending_status(kvm, irq);
if (ret) {
- kfree(irq);
+ vgic_put_irq(kvm, irq);
return ERR_PTR(ret);
}
Let me know if you agree with that.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2020-04-16 17:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 3:03 [PATCH 0/2] KVM: arm64: vgic_irq: Fix memory leaks Zenghui Yu
2020-04-14 3:03 ` Zenghui Yu
2020-04-14 3:03 ` Zenghui Yu
2020-04-14 3:03 ` [PATCH 1/2] KVM: arm64: vgic-v3: Retire all pending LPIs on vcpu destroy Zenghui Yu
2020-04-14 3:03 ` Zenghui Yu
2020-04-14 3:03 ` Zenghui Yu
2020-04-14 10:54 ` Marc Zyngier
2020-04-14 10:54 ` Marc Zyngier
2020-04-14 10:54 ` Marc Zyngier
2020-04-14 11:17 ` Zenghui Yu
2020-04-14 11:17 ` Zenghui Yu
2020-04-14 11:17 ` Zenghui Yu
2020-04-14 13:15 ` Marc Zyngier
2020-04-14 13:15 ` Marc Zyngier
2020-04-14 13:15 ` Marc Zyngier
2020-04-14 3:03 ` [PATCH 2/2] KVM: arm64: vgic-its: Fix memory leak on the error path of vgic_add_lpi() Zenghui Yu
2020-04-14 3:03 ` Zenghui Yu
2020-04-14 3:03 ` Zenghui Yu
2020-04-16 1:17 ` Zenghui Yu
2020-04-16 1:17 ` Zenghui Yu
2020-04-16 1:17 ` Zenghui Yu
2020-04-16 17:23 ` Marc Zyngier [this message]
2020-04-16 17:23 ` Marc Zyngier
2020-04-16 17:23 ` Marc Zyngier
2020-04-17 6:40 ` Zenghui Yu
2020-04-17 6:40 ` Zenghui Yu
2020-04-17 6:40 ` Zenghui Yu
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=2173e13527cc9578838f0364ad29f6cc@kernel.org \
--to=maz@kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yuzenghui@huawei.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.