From owner-cvs-src@FreeBSD.ORG Tue Mar 25 14:30:17 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D63037B401 for ; Tue, 25 Mar 2003 14:30:17 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2BB3343FD7 for ; Tue, 25 Mar 2003 14:30:15 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 10100 invoked from network); 25 Mar 2003 22:30:14 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 25 Mar 2003 22:30:14 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 25 Mar 2003 16:26:51 -0600 (CST) From: Mike Silbersack To: Maxime Henrion In-Reply-To: <20030325222016.GF57674@elvis.mu.org> Message-ID: <20030325162048.H1250@odysseus.silby.com> References: <200303250545.h2P5j5PM008552@repoman.freebsd.org> <20030325222016.GF57674@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-26.2 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf options src/sys/netinet ip_output.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2003 22:30:20 -0000 On Tue, 25 Mar 2003, Maxime Henrion wrote: > Looks like there is a bug in this code. I tried to understand what's > wrong in the if_xl code that tries to deal with mbuf chains containing > more than XL_MAXFRAGS mbufs, and noticed that m_head->m_pkthdr.len isn't > set properly. The length of an mbuf chain shouldn't change when we're > just splitting it into more mbufs, so this is kinda weird. Using > m_fixhdr() just after the splitting code solves it, but that's probably > just a workaround, and either m_split() or the MBUF_FRAG_TEST code needs > to be fixed. Hm, the bug's probably in the frag test code. I'll take a look at it later tonight, but you're welcome to fix it in the meantime. Sorry about the m_copypacket confusion, I misremembered how the error case was handled. Looks like I overstated the seriousness (or existence?) of this problem. Mike "Silby" Silbersack