From: Christoffer Dall <cdall@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>,
Kristina Martsenko <kristina.martsenko@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/7] KVM: arm/arm64: vgic-its: Check result of allocation before use
Date: Mon, 20 Nov 2017 15:58:14 +0100 [thread overview]
Message-ID: <20171120145814.GM28855@cbox> (raw)
In-Reply-To: <20171116175821.26544-5-marc.zyngier@arm.com>
On Thu, Nov 16, 2017 at 05:58:18PM +0000, Marc Zyngier wrote:
> We miss a test against NULL after allocation.
>
> Fixes: 6d03a68f8054 ("KVM: arm64: vgic-its: Turn device_id validation into generic ID validation")
> Cc: stable@vger.kernel.org # 4.8
> Reported-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> virt/kvm/arm/vgic/vgic-its.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index 370086006838..30f7c7e6d2f4 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -821,6 +821,8 @@ static int vgic_its_alloc_collection(struct vgic_its *its,
> return E_ITS_MAPC_COLLECTION_OOR;
>
> collection = kzalloc(sizeof(*collection), GFP_KERNEL);
> + if (!collection)
> + return -ENOMEM;
Our processing of this return value seems to be "shrug, something went
wrong, let's move on to the next command". Is this really a valid thing
to do if we're so much under memory pressure that we dannot allocate a
collection structure?
My question notwithstanding:
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
>
> collection->collection_id = coll_id;
> collection->target_addr = COLLECTION_NOT_MAPPED;
> --
> 2.14.2
>
WARNING: multiple messages have this Message-ID (diff)
From: cdall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/7] KVM: arm/arm64: vgic-its: Check result of allocation before use
Date: Mon, 20 Nov 2017 15:58:14 +0100 [thread overview]
Message-ID: <20171120145814.GM28855@cbox> (raw)
In-Reply-To: <20171116175821.26544-5-marc.zyngier@arm.com>
On Thu, Nov 16, 2017 at 05:58:18PM +0000, Marc Zyngier wrote:
> We miss a test against NULL after allocation.
>
> Fixes: 6d03a68f8054 ("KVM: arm64: vgic-its: Turn device_id validation into generic ID validation")
> Cc: stable at vger.kernel.org # 4.8
> Reported-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> virt/kvm/arm/vgic/vgic-its.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index 370086006838..30f7c7e6d2f4 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -821,6 +821,8 @@ static int vgic_its_alloc_collection(struct vgic_its *its,
> return E_ITS_MAPC_COLLECTION_OOR;
>
> collection = kzalloc(sizeof(*collection), GFP_KERNEL);
> + if (!collection)
> + return -ENOMEM;
Our processing of this return value seems to be "shrug, something went
wrong, let's move on to the next command". Is this really a valid thing
to do if we're so much under memory pressure that we dannot allocate a
collection structure?
My question notwithstanding:
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
>
> collection->collection_id = coll_id;
> collection->target_addr = COLLECTION_NOT_MAPPED;
> --
> 2.14.2
>
next prev parent reply other threads:[~2017-11-20 14:58 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 17:58 [PATCH 0/7] KVM/ARM fixes for 4.15-rc1 Marc Zyngier
2017-11-16 17:58 ` Marc Zyngier
2017-11-16 17:58 ` [PATCH 1/7] KVM: arm/arm64: vgic-irqfd: Fix MSI entry allocation Marc Zyngier
2017-11-16 17:58 ` Marc Zyngier
2017-11-20 14:49 ` Christoffer Dall
2017-11-20 14:49 ` Christoffer Dall
2017-11-16 17:58 ` [PATCH 2/7] KVM: arm/arm64: vgic: Preserve the revious read from the pending table Marc Zyngier
2017-11-16 17:58 ` Marc Zyngier
2017-11-20 14:52 ` Christoffer Dall
2017-11-20 14:52 ` Christoffer Dall
2017-11-16 17:58 ` [PATCH 3/7] KVM: arm/arm64: vgic-its: " Marc Zyngier
2017-11-16 17:58 ` Marc Zyngier
2017-11-20 14:56 ` Christoffer Dall
2017-11-20 14:56 ` Christoffer Dall
2017-11-16 17:58 ` [PATCH 4/7] KVM: arm/arm64: vgic-its: Check result of allocation before use Marc Zyngier
2017-11-16 17:58 ` Marc Zyngier
2017-11-20 14:58 ` Christoffer Dall [this message]
2017-11-20 14:58 ` Christoffer Dall
2017-11-21 11:12 ` Marc Zyngier
2017-11-21 11:12 ` Marc Zyngier
2017-11-16 17:58 ` [PATCH 5/7] KVM: arm/arm64: vgic-v4: Only perform an unmap for valid vLPIs Marc Zyngier
2017-11-16 17:58 ` Marc Zyngier
2017-11-20 15:10 ` Christoffer Dall
2017-11-20 15:10 ` Christoffer Dall
2017-11-16 17:58 ` [PATCH 6/7] arm64: KVM: fix VTTBR_BADDR_MASK BUG_ON off-by-one Marc Zyngier
2017-11-16 17:58 ` Marc Zyngier
2017-11-16 17:58 ` [PATCH 7/7] arm: KVM: Fix " Marc Zyngier
2017-11-16 17:58 ` Marc Zyngier
2017-11-20 13:29 ` Christoffer Dall
2017-11-20 13:29 ` Christoffer Dall
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=20171120145814.GM28855@cbox \
--to=cdall@linaro.org \
--cc=kristina.martsenko@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=takahiro.akashi@linaro.org \
/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.