linux-kernel - Re: [PATCH] net: Adjust softirq raising in __napi

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: <1256547380.28230.17.camel@johannes.local>
Date:	Mon, 26 Oct 2009 09:56:20 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Tilman Schmidt <tilman@...p.cc>
Cc:	Jarek Poplawski <jarkao2@...il.com>,
	David Miller <davem@...emloft.net>, hidave.darkstar@...il.com,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	linux-wireless@...r.kernel.org, linux-ppp@...r.kernel.org,
	netdev@...r.kernel.org, paulus@...ba.org,
	Michael Buesch <mb@...sch.de>,
	Oliver Hartkopp <oliver@...tkopp.net>
Subject: Re: [PATCH] net: Adjust softirq raising in __napi_schedule

On Mon, 2009-10-26 at 10:47 +0200, Tilman Schmidt wrote:

> > However, I lost track now of why we're discussing this.
> 
> The starting point were several reports of the kernel message:
> 
> NOHZ: local_softirq_pending 08
> 
> Originally most if not all of them came from wireless networking,
> but I muddied the waters by adding to the mix a case involving ISDN.
> You stated that all the solutions proposed so far were wrong, so
> we're naturally turning to you for guidance on what the right
> solution might be.

Right. Sorry about getting lost here.

> > Basically it boils down to using netif_rx() when in (soft)irq, and
> > netif_rx_ni() when in process context. That could just be an
> > optimisation, but it's a very valid one.
> 
> Hmmm. That seems to contradict your earlier statement to me that
> simply replacing a call to netif_rx() by one to netif_rx_ni()
> when not in interrupt context isn't a valid solution either.
> What am I missing?

Well, I think you misunderstood me. It would be correct to do this, if
and only if the code that calls it doesn't need the extra guarantee.

Any code (say ISDN code) that calls netif_rx() is clearly assuming to
always be running in (soft)irq context, otherwise it couldn't call
netif_rx() unconditionally. Agree so far?

So now if you change the ISDN code to call netif_rx_ni(), you've changed
the assumption that the ISDN code makes -- that it is running in
(soft)irq context. Therefore, you need to verify that this is actually a
correct change, which is what I tried to say.

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)