> -----Original Message----- > From: Dexuan Cui > Sent: Tuesday, March 14, 2017 5:49 AM > To: KY Srinivasan <kys@xxxxxxxxxxxxx>; gregkh@xxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; > apw@xxxxxxxxxxxxx; vkuznets@xxxxxxxxxx; jasowang@xxxxxxxxxx; > leann.ogasawara@xxxxxxxxxxxxx; marcelo.cerri@xxxxxxxxxxxxx > Cc: stable@xxxxxxxxxxxxxxx > Subject: RE: [PATCH 1/1] Drivers: hv: vmbus: Don't leak channel ids > > > From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel- > > owner@xxxxxxxxxxxxxxx] On Behalf Of kys@xxxxxxxxxxxxxxxxxxxxxx > > > > 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