netdev - Re: mac80211: NOHZ: local_softirq

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]

Message-Id: <200909301633.04376.mb@bu3sch.de>
Date:	Wed, 30 Sep 2009 16:33:02 +0200
From:	Michael Buesch <mb@...sch.de>
To:	Oliver Hartkopp <socketcan@...tkopp.net>
Cc:	"John W. Linville" <linville@...driver.com>,
	Kalle Valo <kalle.valo@....fi>, linux-wireless@...r.kernel.org,
	netdev@...r.kernel.org, Johannes Berg <johannes@...solutions.net>
Subject: Re: mac80211: NOHZ: local_softirq_pending 08

On Wednesday 30 September 2009 13:56:12 Oliver Hartkopp wrote:
> John W. Linville wrote:
> > On Sat, Sep 12, 2009 at 06:41:12PM +0200, Oliver Hartkopp wrote:
> > 
> >> i cooked a patch that introduces netif_rx_ti() and fixes up the problems in
> >> mac80211 and the CAN subsystem.
> > 
> > Oliver,
> > 
> > Are you going to send this patch to Dave?  If you want me to carry
> > it instead, please resend it with a proper changelog including a
> > Signed-off-by line.  For that matter, Dave will most certainly want
> > that as well...
> 
> Hello John,
> 
> as i wrote here
> 
> http://marc.info/?l=linux-netdev&m=125277885910179&w=2
> 
> there are currently only three occurrences of checks that use netif_rx() and
> netif_rx_ni() depending on in_interrupt().
> 
> And regarding the suggested fix from Michael, that checked every(!) netif_rx()
> whether it is in interrupt or not, i was unsure if a netif_tx_ti() would make
> sense for only three cases?!?
> 
> If you think it makes sense, i can post a patch for that ... but:
> 
> Indeed it costs some additional investigation to prove whether netif_rx() or
> netif_rx_ni() should be used in each case. But IMHO this has to be done before
> providing a pump-gun function that solves the problem without thinking if we
> are in irq-context or not. I want to avoid that people are using netif_rx_ti()
> as some kind of default ...
> 
> I don't know how expensive in_interrupt() is, but it IMO should be avoided
> when the context for a code section can be determined in another way.

What if we just get the fix merged and discuss later whether it's worth to optimize a picosecond or not??
My patch fixes the _bug_. You can merge a more "efficient" fix later that saves one or two CPU cycles.

-- 
Greetings, Michael.
--
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