From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kieran Mansley Subject: Re: [Xen-devel] Re: [PATCH 3/4] [Net] Support Xen accelerated network plugin modules Date: Tue, 22 May 2007 13:44:28 +0100 Message-ID: <1179837868.28562.22.camel@moonstone.uk.level5networks.com> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Stephen Hemminger , muli@il.ibm.com, netdev@vger.kernel.org, xen-devel@lists.xensource.com, herbert@gondor.apana.org.au To: Keir Fraser Return-path: Received: from 216-237-3-220.orange.nextweb.net ([216.237.3.220]:11974 "EHLO OCEX01.SolarFlarecom.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756203AbXEVMoc (ORCPT ); Tue, 22 May 2007 08:44:32 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Tue, 2007-05-22 at 08:48 +0100, Keir Fraser wrote: > > > On 22/5/07 08:28, "Kieran Mansley" wrote: > > > On Tue, 2007-05-22 at 08:15 +0100, Kieran Mansley wrote: > >> RCU on its own wouldn't > >> prevent the accelerated plugin being unloaded while netfront was using > >> one of the hooks. > > > > Hmm, actually I think it could be used to do that. I'll take a look. > > Eagerly zap the function pointers, then wait one RCU period so every CPU > goes through a quiescent point before unloading the module? > > -- Keir Am I right in thinking that if one of the functions that was protected by RCU was to block, that would be a bad thing? Clearly the data path hooks can't/don't block, but I'm not sure it's so obvious for things like probing a new device. Kieran