Date: Wed, 14 Sep 2011 21:15:38 +0800 From: Adrian Chadd <adrian@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-net@freebsd.org, Ryan Stone <rysto32@gmail.com>, Jack Vogel <jfvogel@gmail.com>, Arnaud Lacombe <lacombar@gmail.com> Subject: Re: FreeBSD 7-STABLE mbuf corruption Message-ID: <CAJ-Vmo=pX7geYPDc1YVqTERY72LmLwKY5A28t6VVuZOoGAYmaw@mail.gmail.com> In-Reply-To: <201109140740.17319.jhb@freebsd.org> References: <CACqU3MUs9Z9GeuGe=8iVp=MWV6eG-tO%2BkHb1znatsTq2uEqwvA@mail.gmail.com> <CACqU3MV7JRxQ_mNeHCk7RVyzETZLAcc3XL=xyZ-qqtPfRxkZeQ@mail.gmail.com> <CAFMmRNwrD-v52iW5%2Bw_hbgL9battHjXSKcOWBTiMnBHM-cURXg@mail.gmail.com> <201109140740.17319.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 September 2011 19:40, John Baldwin <jhb@freebsd.org> wrote: > You should probably commit that. =A0I wonder if it should be a KASSERT() = also so > that it outright panics on a kernel with INVARIANTS enabled so developers= will > go fix their code as it seems to me to likely be a bug to enqueue a task = that > many times. Or maybe warn? If it's used per-interrupt (like say it is under ath, but for a 10GE NIC doing a high packet rate) then you may end up enqueuing the taskqueue quite often before it next gets a chance to run. Otherwise the code will have to add some more locking and tracking of its own to only enqueue the task once. As I said, I'm just worried that some of the taskqueue users are doing some kind of poor mans refcounting where n(taskqueue_enqueue) references has to equal the npending field in the taskqueue callback. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=pX7geYPDc1YVqTERY72LmLwKY5A28t6VVuZOoGAYmaw>