Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752074AbZJWNfy (ORCPT ); Fri, 23 Oct 2009 09:35:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751641AbZJWNfA (ORCPT ); Fri, 23 Oct 2009 09:35:00 -0400 Received: from xc.sipsolutions.net ([83.246.72.84]:43320 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751607AbZJWNe6 (ORCPT ); Fri, 23 Oct 2009 09:34:58 -0400 Subject: Re: [PATCH] net: Adjust softirq raising in __napi_schedule From: Johannes Berg To: Jarek Poplawski Cc: Tilman Schmidt , David Miller , hidave.darkstar@gmail.com, linux-kernel@vger.kernel.org, tglx@linutronix.de, linux-wireless@vger.kernel.org, linux-ppp@vger.kernel.org, netdev@vger.kernel.org, paulus@samba.org, Michael Buesch , Oliver Hartkopp In-Reply-To: <20091021213947.GA12202@ami.dom.local> References: <4AD31213.6020006@imap.cc> <20091015114052.GA9870@ff.dom.local> <4AD76184.6030900@gmail.com> <4ADF5710.4030505@imap.cc> <20091021211906.GA11401@ami.dom.local> <1256160330.12174.2.camel@johannes.local> <20091021213947.GA12202@ami.dom.local> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-CucNFXYmnSnNQhEM6i4T" Date: Thu, 22 Oct 2009 10:27:01 +0200 Message-Id: <1256200021.12174.11.camel@johannes.local> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2544 Lines: 64 --=-CucNFXYmnSnNQhEM6i4T Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2009-10-21 at 23:39 +0200, Jarek Poplawski wrote: > > > - __raise_softirq_irqoff(NET_RX_SOFTIRQ); > > > + raise_softirq_irqoff(NET_RX_SOFTIRQ); > >=20 > > This still doesn't make any sense. > >=20 > > There may or may not be a lot of code that assumes that everything else > > is run with other tasklets disabled, and that it cannot be interrupted > > by a tasklet and thus create a race. > >=20 > > Can you prove that is not the case, across the entire networking layer? >=20 > I'm not sure I can understand your question. This patch is mainly to > avoid using netif_rx()/netif_rx_ni() pair as a test of proper process > context handling; IMHO there're better tools for this (lockdep, > WARN_ON's). And how exactly does that matter to the patch at hand?! I'm saying that it seems to me, as indicated by the API (and without proof otherwise that's how it is) the networking layer needs to have packets handed to it with softirqs disabled. Therefore, this patch is not needed. While it may not be _wrong_, it'll definitely introduce a performance regression. This really should be obvious. You're fixing the warning at the source of the warning, rather than the source of the problem. johannes --=-CucNFXYmnSnNQhEM6i4T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIcBAABAgAGBQJK4BdSAAoJEODzc/N7+QmazNcP/1JmQK9nI+Lg9fAQRj+Anj4h dzuASnI6MGz+uSIueUNPQN7uv57tvD17jsftZzgR2MawI6WDJSNR6qZM2eICXKa6 HUfxBlByQ7mQN+IuigMlop1ZGTHza7UjUVQq/YLsVU99y4LwAPZJIYddAbtiXzWq xrOPSSc1QUIjfgZct+FlJBrdS/G0JIxCNwyD7HyJcxaSyOuNW/lmqg7YEF6hnoCV NBVCszM0KUHaxQVumy97YnaIOvxC8w+fVycI4kvWDhKLhHfwowc+Vi3/Pkb5ofML WaWTvaoEGeml99YD2uprZb5vKWmKGm4NxHJr2s/3AC0xbDVLsXDg9hPVZdTwVE0d Hx4L4uYQC4hr9+TRrFBDYqymbYgbJ0ZufdrIwicygQBpOZfLDmx7M47LDGlbJ7D3 LfE5PWu3C0+qegi9k5MI8w6DlyVlVAnG6jgWGgyNle5fOCg7cmN+IBGl57XrTVPF G1vRBDSFzBLDUQPRkBrwDO7rDNRoB3xiOAQiDNsKf1h0zdsDY4PlgOKlT6A6sVMC 8UqB5D1nLM57IShUH+0bypp9GNEN7q2XGge8nyXYKDsMlPZjLOJMMUR5IdJZxnbS CeIWTQqoqu/inV381OWn4S20tofOQI38F4h4WOWswLUlRbWh+HDPTnfJpeim2Z7q u6tvV3UkEoicmPfJcqbD =aeCA -----END PGP SIGNATURE----- --=-CucNFXYmnSnNQhEM6i4T-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/