From nobody@FreeBSD.org  Fri May  8 01:54:30 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 8B33E106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  8 May 2009 01:54:30 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 79B618FC18
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  8 May 2009 01:54:30 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n481sUxY048567
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 8 May 2009 01:54:30 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n481sUWh048544;
	Fri, 8 May 2009 01:54:30 GMT
	(envelope-from nobody)
Message-Id: <200905080154.n481sUWh048544@www.freebsd.org>
Date: Fri, 8 May 2009 01:54:30 GMT
From: Martin Karsten <mkarsten@cs.uwaterloo.ca>
To: freebsd-gnats-submit@FreeBSD.org
Subject: cooments for m_getm2 inconsistent with behaviour
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         134355
>Category:       kern
>Synopsis:       [mbuf] comments for m_getm2 inconsistent with behaviour
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    andre
>State:          analyzed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri May 08 02:00:08 UTC 2009
>Closed-Date:    
>Last-Modified:  Tue Aug 24 08:24:47 UTC 2010
>Originator:     Martin Karsten
>Release:        7.2
>Organization:
University of Waterloo
>Environment:
FreeBSD i01.expnet 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May  1 08:49:13 UTC 2009     root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

>Description:
It seems to me that the comments describing m_getm2 are inconsistent with the behaviour. The comment states that the function returns the top of the newly allocated chain, but it in fact returns the top of the overall chain.

>How-To-Repeat:
N/A

>Fix:
To return the top of the newly allocated chain, the last statement in line 151 would need to be changed from

  return (m);

to

  return (nm);

and the very last else-clause before that is not needed.


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Fri May 8 03:36:00 UTC 2009 
State-Changed-Why:  
To which part of the tree does this apply? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=134355 

From: Martin Karsten <mkarsten@cs.uwaterloo.ca>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/134355: comments for m_getm2 inconsistent with behaviour
Date: Fri, 08 May 2009 14:46:22 -0400

 Sorry, I'm not familiar with the development tree. I've found it in
 
 /usr/src/sys/kern/uipc_mbuf.c
 
 on a 7.2-RELEASE system.
 
 Thanks,
 Martin
State-Changed-From-To: feedback->open 
State-Changed-By: linimon 
State-Changed-When: Mon May 11 16:45:31 UTC 2009 
State-Changed-Why:  
feedback received. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=134355 

From: Mark Linimon <linimon@lonesome.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/134355: comments for m_getm2 inconsistent with behaviour
Date: Mon, 11 May 2009 11:46:21 -0500

 ----- Forwarded message from Martin Karsten <mkarsten@cs.uwaterloo.ca> -----
 
 From: Martin Karsten <mkarsten@cs.uwaterloo.ca>
 To: linimon@FreeBSD.org
 CC: freebsd-bugs@FreeBSD.org
 Subject: Re: kern/134355: comments for m_getm2 inconsistent with behaviour
 
 Sorry, I'm not familiar with the development tree. I've found it in
 
 /usr/src/sys/kern/uipc_mbuf.c
 
 on a 7.2-RELEASE system.
 
 Thanks,
 Martin
 
 linimon@FreeBSD.org wrote:
 > Old Synopsis: cooments for m_getm2 inconsistent with behaviour
 > New Synopsis: comments for m_getm2 inconsistent with behaviour
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: linimon
 > State-Changed-When: Fri May 8 03:36:00 UTC 2009
 > State-Changed-Why: 
 > To which part of the tree does this apply?
 > 
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=134355
 
 
 ----- End forwarded message -----
State-Changed-From-To: open->analyzed 
State-Changed-By: vwe 
State-Changed-When: Wed Jun 17 20:07:52 UTC 2009 
State-Changed-Why:  
Martin, 
thank you for your submission. 
In the first place I thought you've found a code bug but while carefully 
analyzing usage of m_getm2(), I haven't been able to to find a sign 
of trouble. I agree current implementation isn't intentional and might 
easily lead into misuse of m_getmw() but the function is rarely used. 
I think the issue can be solved by "fixing" the leading comment by 
something like the following. 

--- uipc_mbuf.c.orig	2009-06-17 22:03:53.000000000 +0200 
+++ uipc_mbuf.c	2009-06-17 22:06:24.000000000 +0200 
@@ -90,8 +90,9 @@ 
* Allocate a given length worth of mbufs and/or clusters (whatever fits 
* best) and return a pointer to the top of the allocated chain.  If an 
* existing mbuf chain is provided, then we will append the new chain 
- * to the existing one but still return the top of the newly allocated 
- * chain. 
+ * to the existing one but still return the top of the pre-existing 
+ * chain. If no pre-existing mbuf chain is given, we return the top 
+ * of the new allocated mbuf chain. 
*/ 
struct mbuf * 
m_getm2(struct mbuf *m, int len, int how, short type, int flags) 


http://www.freebsd.org/cgi/query-pr.cgi?pr=134355 
Responsible-Changed-From-To: freebsd-bugs->andre 
Responsible-Changed-By: andre 
Responsible-Changed-When: Tue Aug 24 08:24:31 UTC 2010 
Responsible-Changed-Why:  
Take over. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=134355 
>Unformatted:
