Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1599905 > unrolled thread
| Started by | kys@exchange.microsoft.com |
|---|---|
| First post | 2017-03-14 00:00 +0100 |
| Last post | 2017-03-14 15:40 +0100 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH 1/1] Drivers: hv: vmbus: Don't leak channel ids kys@exchange.microsoft.com - 2017-03-14 00:00 +0100
RE: [PATCH 1/1] Drivers: hv: vmbus: Don't leak channel ids Dexuan Cui <decui@microsoft.com> - 2017-03-14 13:50 +0100
RE: [PATCH 1/1] Drivers: hv: vmbus: Don't leak channel ids KY Srinivasan <kys@microsoft.com> - 2017-03-14 15:40 +0100
| From | kys@exchange.microsoft.com |
|---|---|
| Date | 2017-03-14 00:00 +0100 |
| Subject | [PATCH 1/1] Drivers: hv: vmbus: Don't leak channel ids |
| Message-ID | <tkH6x-7El-3@gated-at.bofh.it> |
From: K. Y. Srinivasan <kys@microsoft.com>
If we cannot allocate memory for the channel, free the relid
associated with the channel.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: <stable@vger.kernel.org>
---
drivers/hv/channel_mgmt.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index e1a3ae4..0a85246 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -802,6 +802,7 @@ static void vmbus_onoffer(struct vmbus_channel_message_header *hdr)
/* Allocate the channel object and save this offer. */
newchannel = alloc_channel();
if (!newchannel) {
+ vmbus_release_relid(offer->child_relid);
pr_err("Unable to allocate channel object\n");
return;
}
--
1.7.1
[toc] | [next] | [standalone]
| From | Dexuan Cui <decui@microsoft.com> |
|---|---|
| Date | 2017-03-14 13:50 +0100 |
| Message-ID | <tkU3L-8W-3@gated-at.bofh.it> |
| In reply to | #1599905 |
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of kys@exchange.microsoft.com
>
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index e1a3ae4..0a85246 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -802,6 +802,7 @@ static void vmbus_onoffer(struct
> vmbus_channel_message_header *hdr)
> /* Allocate the channel object and save this offer. */
> newchannel = alloc_channel();
> if (!newchannel) {
> + vmbus_release_relid(offer->child_relid);
> pr_err("Unable to allocate channel object\n");
> return;
> }
The patch seems good.
BTW, vmbus_onoffer -> alloc_channel is only called in the workqueue
context, so maybe we should change the atomic kzalloc in alloc_channel
to GFP_KERNEL?
Thanks,
-- Dexuan
[toc] | [prev] | [next] | [standalone]
| From | KY Srinivasan <kys@microsoft.com> |
|---|---|
| Date | 2017-03-14 15:40 +0100 |
| Message-ID | <tkVMd-1qV-7@gated-at.bofh.it> |
| In reply to | #1600290 |
> -----Original Message-----
> From: Dexuan Cui
> Sent: Tuesday, March 14, 2017 5:49 AM
> To: KY Srinivasan <kys@microsoft.com>; gregkh@linuxfoundation.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org; olaf@aepfle.de;
> apw@canonical.com; vkuznets@redhat.com; jasowang@redhat.com;
> leann.ogasawara@canonical.com; marcelo.cerri@canonical.com
> Cc: stable@vger.kernel.org
> Subject: RE: [PATCH 1/1] Drivers: hv: vmbus: Don't leak channel ids
>
> > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> > owner@vger.kernel.org] On Behalf Of kys@exchange.microsoft.com
> >
> > diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> > index e1a3ae4..0a85246 100644
> > --- a/drivers/hv/channel_mgmt.c
> > +++ b/drivers/hv/channel_mgmt.c
> > @@ -802,6 +802,7 @@ static void vmbus_onoffer(struct
> > vmbus_channel_message_header *hdr)
> > /* Allocate the channel object and save this offer. */
> > newchannel = alloc_channel();
> > if (!newchannel) {
> > + vmbus_release_relid(offer->child_relid);
> > pr_err("Unable to allocate channel object\n");
> > return;
> > }
>
> The patch seems good.
>
> BTW, vmbus_onoffer -> alloc_channel is only called in the workqueue
> context, so maybe we should change the atomic kzalloc in alloc_channel
> to GFP_KERNEL?
No; this will introduce potential reordering of execution. I am working on rescind handling
where, we need to ensure temporal ordering of events until the channel is created.
K. Y
>
> Thanks,
> -- Dexuan
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web