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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 11 Aug 2016 09:22:53 -0500
From:	Timur Tabi <timur@...eaurora.org>
To:	Florian Fainelli <f.fainelli@...il.com>,
	Lino Sanfilippo <LinoSanfilippo@....de>,
	netdev@...r.kernel.org, devicetree@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, sdharia@...eaurora.org,
	shankerd@...eaurora.org, vikrams@...eaurora.org,
	cov@...eaurora.org, gavidov@...eaurora.org, robh+dt@...nel.org,
	andrew@...n.ch, bjorn.andersson@...aro.org, mlangsdo@...hat.com,
	jcm@...hat.com, agross@...eaurora.org, davem@...emloft.net
Subject: Re: [PATCH] [v7] net: emac: emac gigabit ethernet controller driver

Florian Fainelli wrote:
>>      netif_stop_queue(netdev);
>> >     napi_disable(&adpt->rx_q.napi);
>> >
>> >I cannot call just napi_disable() in emac_change_mtu(), because when I
>> >then call emac_mac_down(), the first thing it does is call
>> >netif_stop_queue(), and that's when I timeout/hang.
> Whatever emac_mac_down() does you can unroll it in the change_mtu
> callback anyway, so if this a problematic sequence you can work around it.

I'm having difficulty coming up with an actual sequence that works. This 
odd interaction between netif_stop_queue() and napi_disable() is giving 
me inconsistent results.

The hang occurs with this loop in napi_disable():

	while (test_and_set_bit(NAPI_STATE_SCHED, &n->state))
		msleep(1);

This loop never exits.  Can you give me a clue as to what could be the 
reason?

>> >Unfortunately, I cannot even do this:
>> >
>> >     netif_stop_queue(netdev);
>> >     napi_disable(&adpt->rx_q.napi);
>> >     netif_stop_queue(netdev);
>> >     napi_disable(&adpt->rx_q.napi);
>> >
>> >Even though I've already called netif_stop_queue(), calling it again
>> >causes the timeout/hang.

> Buf if this is really what you copy/pasted here, why do this twice anyway?

Sorry, what I meant was that I was hoping that *both* emac_change_mtu() 
and emac_mac_down() could do

	netif_stop_queue(netdev);
	napi_disable(&adpt->rx_q.napi);

Which would have the effect of what I wrote above.

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ