netdev - RE: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be processed during probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 20 Jul 2015 19:00:09 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Dexuan Cui <decui@...rosoft.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"olaf@...fle.de" <olaf@...fle.de>,
	"apw@...onical.com" <apw@...onical.com>,
	"jasowang@...hat.com" <jasowang@...hat.com>,
	"vkuznets@...hat.com" <vkuznets@...hat.com>
Subject: RE: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be
 processed during probe



> -----Original Message-----
> From: Dexuan Cui
> Sent: Monday, July 20, 2015 2:39 AM
> To: KY Srinivasan; davem@...emloft.net; netdev@...r.kernel.org; linux-
> kernel@...r.kernel.org; devel@...uxdriverproject.org; olaf@...fle.de;
> apw@...onical.com; jasowang@...hat.com; vkuznets@...hat.com
> Subject: RE: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be
> processed during probe
> 
> > From: KY Srinivasan
> > Sent: Friday, July 17, 2015 23:33
> > > From: Dexuan Cui
> > > Sent: Friday, July 17, 2015 3:01 AM
> > > > From: K. Y. Srinivasan
> > > > Sent: Friday, July 17, 2015 3:17
> > > > Subject: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be
> > > processed
> > > > during probe
> > > > diff --git a/drivers/net/hyperv/hyperv_net.h
> > > b/drivers/net/hyperv/hyperv_net.h
> > > > ...
> > > > @@ -1116,6 +1127,9 @@ int rndis_filter_device_add(struct hv_device
> > > *dev,
> > > >  num_possible_rss_qs = cpumask_weight(node_cpu_mask);
> > > >  net_device->num_chn = min(num_possible_rss_qs, num_rss_qs);
> > > >
> > > > +num_rss_qs = net_device->num_chn - 1;
> > > > +net_device->num_sc_offered = num_rss_qs;
> > > > +
> > > >  if (net_device->num_chn == 1)
> > > >  goto out;
> > > >
> > > > @@ -1157,11 +1171,22 @@ int rndis_filter_device_add(struct
> hv_device
> > > *dev,
> > > >
> > > >  ret = rndis_filter_set_rss_param(rndis_device, net_device-
> > > >num_chn);
> > > >
> > > > +/*
> > > > + * Wait for the host to send us the sub-channel offers.
> > > > + */
> > > > +spin_lock_irqsave(&net_device->sc_lock, flags);
> > > > +sc_delta = net_device->num_chn - 1 - num_rss_qs;
> > > > +net_device->num_sc_offered -= sc_delta;
> > >
> > > Hi KY,
> > > IMO here the "-= " should be "+="?
> > >
> > > I think sc_delta is usually <= 0, meaning the host may allocate less
> > > subchannels than
> > > we expect.
> > > With "-=", net_device->num_sc_offered can become bigger -- this
> doesn't
> > > seem correct.
> > We control how many sub-channels we want the host to offer (say
> > sc_requested). Based on this
> > number we begin to track how many have actually been processed - we
> > decrement sc_requested
> > each time a sub-channel offer is processed. If the host were to actually
> offer all
> > that we have requested,
> > then checking for sc_requested to be zero is sufficient to ensure that we
> have
> > processed all the
> > potentially in-flight sub-channels. However, the host  may choose to offer
> less
> > than what we had asked for
> > and the variable "delta" is tracking this difference. Since we are counting
> down
> > from what we had asked for
> > we have to subtract "delta" for proper accounting.
> 
> Yes, I understand the rationale.
> Let me show the issue by example:
> 
> Let's assume sc_requested is 7 and the host actually only offers 3 sub-
> channels:
> 1. Just before sending the NVSP_MSG5_TYPE_SUBCHANNEL message, we
> have
> net_device->num_chn == 8,
> num_rss_qs ==  7
> net_device->num_sc_offered == 7
> 
> 2. Just after we get the reply of the message,
> net_device->num_chn == 4
> sc_delta = net_device->num_chn - 1 - num_rss_qs, so sc_delta == 4 - 1 - 7 = -
> 4
> net_device->num_sc_offered -= sc_delta, so
> net_device->num_sc_offered == 7 - (-4) = 11. It's not zero, so we sleep on
> the
> wait_for_completion().
> 
> 3. Now we process the 3 sub-channel and net_device->num_sc_offered will
> become 11 -1 -1 -1 == 8 and no complete() will be invoked!
> 
> That's why I think the "-=" in the line
> net_device->num_sc_offered -= sc_delta
> should be "+=".

Thanks Dexuan; I will fix the issue and resend.

Regards,

K. Y
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html