From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 21:35:07 2012 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 58A4D106566B for ; Thu, 2 Feb 2012 21:35:07 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D4BF68FC0A for ; Thu, 2 Feb 2012 21:35:06 +0000 (UTC) Received: by bkbzx1 with SMTP id zx1so3491687bkb.13 for ; Thu, 02 Feb 2012 13:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=4t049EILxu8I/is1orxZWLsYDTlLA1oozBfUC9FLzMM=; b=uB5OejTJbZmp8IqZmXEGn20tYKxaFE1A437Tyus+Dp+tWsh9UEZlNUWqKQtOw7m0Ws ljySeTGTDaqk/LS+Uxi7TxgFU6/9x2llY9von7YLYJpCo8PMpiRMTCTaXQS9D2j33ABI oxR/0eLrZVfI5mvMBMvljSiR+6GfCo51gm4nM= Received: by 10.204.128.146 with SMTP id k18mr631741bks.92.1328218505634; Thu, 02 Feb 2012 13:35:05 -0800 (PST) Received: from rimwks1w7x64 ([31.47.167.64]) by mx.google.com with ESMTPS id cg2sm10539612bkb.12.2012.02.02.13.35.03 (version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 13:35:04 -0800 (PST) From: rozhuk.im@gmail.com To: "'Navdeep Parhar'" References: <4f298d95.82b7cc0a.49b2.5d24@mx.google.com> In-Reply-To: Date: Fri, 3 Feb 2012 06:34:57 +0900 Message-ID: <4f2b0188.82b7cc0a.2dad.ffff88e9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru thread-index: Aczhd2nXLNgvfTXZRBuxTnSGGa9qNAAeGNxA Cc: freebsd-net@freebsd.org Subject: RE: m_pullup - fail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 21:35:07 -0000 The function does not allow access to data if m_flags & M_EXT size and more MHLEN, although the data is actually available. Why if there is no m_flags & M_PKTHDR size anyway MHLEN instead MLEN? As an improvement, you can try to copy the data from the current m in m_next, if m is not enough space and enough m_next (case m_flags & M_EXT). If I figured out MBUF then m_pullup should take maximum length according to this macro #define M_PULLUP_MAX(m) \ ((m)->m_flags & M_EXT ? \ (M_WRITABLE(m) ? (m)->m_ext.ext_size : 0) : \ (m)->m_flags & M_PKTHDR ? MHLEN : MLEN ) /usr/src/sys/sys/param.h:#define MSIZE 256 /* size of an mbuf */ /usr/src/sys/sys/mbuf.h:#define MLEN (MSIZE - sizeof(struct m_hdr)) /* normal data len */ /usr/src/sys/sys/mbuf.h:#define MHLEN (MLEN - sizeof(struct pkthdr)) /* data len w/pkthdr */ #define M_EXT 0x00000001 /* has associated external storage */ /* * If first mbuf has no cluster, and has room for len bytes * without shifting current data, pullup into it, * otherwise allocate a new mbuf to prepend to the chain. */ if ((n->m_flags & M_EXT) == 0 && n->m_data + len < &n->m_dat[MLEN] && n->m_next) { if (n->m_len >= len) return (n); m = n; n = n->m_next; len -= m->m_len; } else { if (len > MHLEN) goto bad; MGET(m, M_DONTWAIT, n->m_type); if (m == NULL) goto bad; m->m_len = 0; if (n->m_flags & M_PKTHDR) M_MOVE_PKTHDR(m, n); } > -----Original Message----- > From: Navdeep Parhar [mailto:nparhar@gmail.com] > Sent: Thursday, February 02, 2012 3:54 PM > To: Rozhuk.IM@gmail.com > Cc: freebsd-net@freebsd.org > Subject: Re: m_pullup - fail > > On Wed, Feb 1, 2012 at 11:07 AM, wrote: > > Hello! > > > > > > The function always returns an error and remove the chain MBUF for > two > > or more generated on the same host. > > If the pre-call m_defrag no error occurs. > > This is normal behavior? > > How to know in advance the maximum size for MBUF that does not cause > a > > failure in m_pullup? > > You can't pullup more than MHLEN bytes into a pkthdr mbuf if it's not > associated with an external cluster. See the last sentence in this > excerpt from mbuf(9): > > m_pullup(mbuf, len) > Arrange that the first len bytes of an mbuf chain are > contiguous > and lay in the data area of mbuf, so they are accessible > with > mtod(mbuf, type). It is important to remember that this may > involve reallocating some mbufs and moving data so all > pointers > referencing data within the old mbuf chain must be > recalculated or > made invalid. Return the new mbuf chain on success, NULL on > fail- > ure (the mbuf chain is freed in this case). Note: It does > not > allocate any mbuf clusters, so len must be less than MHLEN. > > Regards, > Navdeep > > > > > > mbuf: 0xfffffe0074fc0600 len: 42, next: 0xfffffe0073a45800, 2 > > mbuf: 0xfffffe0073a45800 len: 210, next: 0, 1 > > FAIL: m_pullup: m_pkthdr.len = 252, m_len = 42, pullup_len = 252 > > > > > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net- > unsubscribe@freebsd.org"