> -----Original Message----- > From: Dexuan Cui > Sent: Tuesday, March 14, 2017 5:49 AM > To: KY Srinivasan <k...@microsoft.com>; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com; > leann.ogasaw...@canonical.com; marcelo.ce...@canonical.com > Cc: sta...@vger.kernel.org > Subject: RE: [PATCH 1/1] Drivers: hv: vmbus: Don't leak channel ids > > > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > > ow...@vger.kernel.org] On Behalf Of k...@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 _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
