netdev - Re: new NAPI quota synchronization issue

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: <20070919150129.7b0967f7@freepuppy.rosehill.hemminger.net>
Date:	Wed, 19 Sep 2007 15:01:29 -0700
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: new NAPI quota synchronization issue

On Wed, 19 Sep 2007 10:35:08 -0700 (PDT)
David Miller <davem@...emloft.net> wrote:

> From: David Miller <davem@...emloft.net>
> Date: Wed, 19 Sep 2007 09:58:25 -0700 (PDT)
> 
> > Probably a good way to deal with this is to simply make the quota
> > handling stateless.
> > 
> > The only reason we handle partial quota usage is to handle the
> > global netdev_budget.  But we can simply "round up" and let
> > netdev_budget get oversubscribed by one napi->quota's worth
> > if necessary.
> > 
> > At that point, n->quota only holds two states when used, full
> > and empty.  And at that point there is no reason to maintain
> > it's value at all.  Only the weight is necessary.
> > 
> > I'll try to post a patch which implements this later today.
> 
> Ok, here is the patch and I've checked it into net-2.6.24 as well.
> 
> There really shouldn't be any fundamental synchronization issues
> in the new NAPI stuff any longer.  I'm pretty sure any problems
> remaining can only be caused by drivers bugs but we'll see :-)
> 
> I went over the list handling several times and it looks bulletproof.
> Only the thread of control that sets the NAPI_STATE_SCHED bit
> atomically will do list modifications, until the thread of control
> that decides unconditionally to clear the bit, which will do a
> list_del() immediately before clearing that bit.
> 
> 

There might be a future problem if some driver decided to change weight
often on the fly?  Perhaps you need to sample it once in start of napi_schedule.
-
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