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
| ||
|
Message-ID: <20071016115318.0fc36af3@freepuppy.rosehill> Date: Tue, 16 Oct 2007 11:53:18 -0700 From: Stephen Hemminger <shemminger@...ux-foundation.org> To: benh@...nel.crashing.org Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Roland Dreier <rdreier@...co.com>, linuxppc-dev list <linuxppc-dev@...abs.org> Subject: Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll On Tue, 16 Oct 2007 15:49:52 +1000 Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote: > net: Add __napi_sycnhronize() to sync with napi poll > > The EMAC driver which needs to handle multiple devices with one > NAPI instance implements its own per-channel disable bit. However, > when setting such a bit, it needs to synchronize with the poller > (that is make sure that any pending poller instance has completed, > or is started late enough to see that disable bit). > > This implements a low level __napi_synchronize() function to acheive > that. The underscores are to emphasis the low level aspect of it and > to discourage driver writers who don't know what they are doing to > use it (to please DaveM :-) > > Signed-off-by: Benjamin Herrenschmidt <benh@...nel.crashing.org> > --- > > (Use correct address for Stephen this time) > > If the approach is accepted, I would like to have this merged now > so the EMAC patch to make it work again can follow :-) > > Note: I use msleep_interruptible(1); just like napi_disable(). However > I'm not too happy that the "hot" loop that results of a pending signal > here will spin without even a cpu_relax ... what do you guys think would > be the best way to handle this ? So this is really just like synchronize_irq()? Using msleep is bogus because you want to spin, you are only waiting for a softirq on the other cpu to finish. If you wait for a whole millisecond and sleep that is far longer than the napi routine should take. You could even optimize it like synchronize_irq() for the non-SMP case. -- Stephen Hemminger <shemminger@...ux-foundation.org> - 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
Powered by blists - more mailing lists