From owner-cvs-all@FreeBSD.ORG Thu Feb 24 23:32:21 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6A3B16A4CE for ; Thu, 24 Feb 2005 23:32:21 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id F0C0C43D54 for ; Thu, 24 Feb 2005 23:32:20 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 3148 invoked from network); 24 Feb 2005 23:32:19 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 24 Feb 2005 23:32:19 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 24 Feb 2005 17:32:18 -0600 (CST) From: Mike Silbersack To: Robert Watson In-Reply-To: Message-ID: <20050224172727.T9200@odysseus.silby.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c src/sys/sys mbuf.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 23:32:22 -0000 On Thu, 24 Feb 2005, Robert Watson wrote: > Sorry, I should have been more specific. A patch is attached. Basically, > 'm_head' can be modified, but on failure, the caller's version of m_head > isn't modified, as it's passed by value, not reference. So the caller may > be using the wrong mbuf. In some cases, the caller doesn't know how to > handle m_head being returned as NULL, and will try to unconditionally > re-insert the mbuf into the interface queue even if it's NULL. I hadn't > realized that was a problem when I wrote the below patch, so haven't > checked if if_rl needs to be tweaked to handle that (most others do need > to be tweaked, so rl probably does also). I don't see what you're seeing. If m_defrag fails, rl_encap frees the mbuf chain, then returns 1. Then, back in rl_start_locked, we have: if (rl_encap(sc, m_head)) break; So that failure causes it to break out of the loop. In the successful m_defrag case, the resulting mbuf is referenced via RL_CUR_TXMBUF(sc), so there's no need to pass m_head back in that case either. What's the problem? Mike "Silby" Silbersack