From owner-freebsd-net@FreeBSD.ORG Wed Sep 14 15:45:57 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A11881065673; Wed, 14 Sep 2011 15:45:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 75D8D8FC14; Wed, 14 Sep 2011 15:45:57 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DD50946B0D; Wed, 14 Sep 2011 11:45:56 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7860E8A037; Wed, 14 Sep 2011 11:45:56 -0400 (EDT) From: John Baldwin To: Adrian Chadd Date: Wed, 14 Sep 2011 10:08:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201109140740.17319.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109141008.16749.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 14 Sep 2011 11:45:56 -0400 (EDT) Cc: freebsd-net@freebsd.org, Ryan Stone , Jack Vogel , Arnaud Lacombe Subject: Re: FreeBSD 7-STABLE mbuf corruption X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 15:45:57 -0000 On Wednesday, September 14, 2011 9:15:38 am Adrian Chadd wrote: > On 14 September 2011 19:40, John Baldwin 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