FreeBSD 7-STABLE mbuf corruption

[John Baldwin]

On Wednesday, September 14, 2011 9:15:38 am Adrian Chadd wrote:
> On 14 September 2011 19:40, John Baldwin <jhb at freebsd.org> wrote:
> 
> > You should probably commit that.  I 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.

I think the real problem is the livelock case where the task just runs forever
as opposed to the task not getting to run for a long time.  However, if you
set rx_processing_limit to -1 (or an equivalent knob) then you are basically
asking for livelock.

> 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.

Very few task routines actually use pending for anything.  The ones that
do are not likely to loop forever either.

-- 
John Baldwin