NetBSD Problem Report #53218
From kardel@mail.kardel.name Fri Apr 27 13:25:31 2018
Return-Path: <kardel@mail.kardel.name>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 24D177A154
for <gnats-bugs@gnats.NetBSD.org>; Fri, 27 Apr 2018 13:25:31 +0000 (UTC)
Message-Id: <20180427132522.4738E28C116@mail.kardel.name>
Date: Fri, 27 Apr 2018 13:25:22 +0000 (UTC)
From: kardel@netbsd.org
Reply-To: kardel@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: bpf tripping over FREEd mbufs
X-Send-Pr-Version: 3.95
>Number: 53218
>Category: kern
>Synopsis: bpf tripping over FREEd mbufs
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Apr 27 13:30:00 +0000 2018
>Closed-Date: Sun May 06 10:35:08 +0000 2018
>Last-Modified: Tue May 15 04:50:01 +0000 2018
>Originator: Frank Kardel
>Release: NetBSD 8.99.14
>Organization:
>Environment:
System: NetBSD gateway 8.99.14 NetBSD 8.99.14 (GATEWAY) #9: Thu Apr 26 21:08:20 CEST 2018 kardel@xxx:/src/NetBSD/act/src/obj.amd64/sys/arch/amd64/compile/GATEWAY amd64
Architecture: x86_64
Machine: amd64
>Description:
multiple times a day bpf m_xhalf() panics due to a NULL pointer access when attempting to extract a 16bit-word from a freed(!) mbuf
the stack trace is:
(gdb) bt
#0 0xffffffff802239b6 in cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at /src/NetBSD/act/src/sys/arch/amd64/amd64/machdep.c:709
#1 0xffffffff80a14229 in vpanic (fmt=0xffffffff811ab288 "FREE mbuf m_buf = %p, m_len = %d, m_flags = 0x%x, m_type = 0x%x\n", ap=ap@entry=0xffff80013cc0b7e8)
at /src/NetBSD/act/src/sys/kern/subr_prf.c:343
^^^ local modification for debugging
#2 0xffffffff80a142c0 in panic (fmt=<optimized out>) at /src/NetBSD/act/src/sys/kern/subr_prf.c:259
#3 0xffffffff80aa6c4d in m_xhalf (m=<optimized out>, k=<optimized out>, err=err@entry=0xffff80013cc0b85c) at /src/NetBSD/act/src/sys/net/bpf_filter.c:165
#4 0xffffffff80aa7055 in bpf_filter_ext (bc=bc@entry=0x0, pc=0xffffe4047bd58648, args=args@entry=0xffff80013cc0b8d8) at /src/NetBSD/act/src/sys/net/bpf_filter.c:374
#5 0xffffffff80aa4310 in bpf_deliver (rcv=<optimized out>, buflen=<optimized out>, pktlen=34818, pkt=0xffffe4047a14ba00, cpfn=0xffffffff80aa2e34 <bpf_mcpy>,
bp=<optimized out>) at /src/NetBSD/act/src/sys/net/bpf.c:1589
#6 _bpf_mtap (bp=<optimized out>, m=<optimized out>) at /src/NetBSD/act/src/sys/net/bpf.c:1678
#7 0xffffffff8033161b in bpf_mtap (_ifp=0xffff8000209e98a0, _m=0xffffe4047a14ba00) at /src/NetBSD/act/src/sys/net/bpf.h:456
#8 ixgbe_mq_start_locked (ifp=0xffff8000209e98a0, txr=0xffffe4011ddef810) at /src/NetBSD/act/src/sys/dev/pci/ixgbe/ix_txrx.c:311
#9 0xffffffff80331825 in ixgbe_mq_start (ifp=0xffff8000209e98a0, m=<optimized out>) at /src/NetBSD/act/src/sys/dev/pci/ixgbe/ix_txrx.c:246
#10 0xffffffff80ab6706 in ether_output (ifp0=0xffff8000209e98a0, m0=<optimized out>, dst=0xffffe4041b4fcce0, rt=0xffffe4047af97a10)
at /src/NetBSD/act/src/sys/net/if_ethersubr.c:459
#11 0xffffffff806ea927 in if_output_lock (rt=0xffffe4047af97a10, dst=0xffffe4041b4fcce0, m=0xffffe4047a14ba00, ifp=0xffff8000209e98a0, cifp=0xffff8000209e98a0)
at /src/NetBSD/act/src/sys/net/if.h:488
#12 ip_if_output (ifp=0xffff8000209e98a0, m=0xffffe4047a14ba00, dst=0xffffe4041b4fcce0, rt=0xffffe4047af97a10) at /src/NetBSD/act/src/sys/netinet/ip_output.c:216
#13 0xffffffff806ec758 in ip_output (m0=m0@entry=0xffffe4047a14ba00, opt=0x0, ro=ro@entry=0xffffe4041ba0ab70, flags=<optimized out>, imo=imo@entry=0x0,
inp=0xffffe4041ba0ab10) at /src/NetBSD/act/src/sys/netinet/ip_output.c:756
#14 0xffffffff806f85a3 in tcp_output (tp=tp@entry=0xffffe40121463030) at /src/NetBSD/act/src/sys/netinet/tcp_output.c:1621
#15 0xffffffff806f42d2 in tcp_input (m=<optimized out>) at /src/NetBSD/act/src/sys/netinet/tcp_input.c:2877
#16 0xffffffff806e4d69 in ip_input (m=<optimized out>) at /src/NetBSD/act/src/sys/netinet/ip_input.c:805
#17 ipintr (arg=<optimized out>) at /src/NetBSD/act/src/sys/netinet/ip_input.c:409
#18 0xffffffff809e8d15 in softint_execute (l=<optimized out>, s=4, si=0xffff80013cc00230) at /src/NetBSD/act/src/sys/kern/kern_softint.c:592
#19 softint_dispatch (pinned=<optimized out>, s=4) at /src/NetBSD/act/src/sys/kern/kern_softint.c:874
#20 0xffffffff8021df5f in Xsoftintr ()
(gdb) print *m0
$6 = {m_hdr = {mh_next = 0xffffe4047ab4a000, mh_nextpkt = 0x0, mh_data = 0x0, mh_owner = 0x0, mh_len = 66, mh_flags = 2, mh_paddr = 19228047872, mh_type = 0}, M_dat = {
MH = {MH_pkthdr = {_rcvif = {ctx = 0x0, index = 0}, tags = {slh_first = 0x0}, len = 34818, csum_flags = 320, csum_data = 1310736, segsz = 1448, ether_vtag = 1138,
pad0 = 29281, pattr_af = 0, pattr_class = 0x0, pattr_hdr = 0x0}, MH_dat = {MH_ext = {ext_ref = 0x8a7301a3f58cba00, ext_storage = {ext_refcnt = 4202349580,
ext_flags = 554809, ext_buf = 0x406930f4870045 <error: Cannot access memory at address 0x406930f4870045>, ext_free = 0x101c80a00000640,
ext_arg = 0x6aa68f008066c80a, ext_size = 7341150177066158914, ext_un = {extun_paddr = 47817566457984, extun_pgs = {0x2b7d65101080, 0xed0000000a080101,
0x10100001abdbb01, 0x1abdbb010a08, 0xed00, 0x0, 0x0, 0x0, 0x496d3743594b4b54, 0x416d0a0d48435a65, 0x6e43684e4a69352f, 0x4b78554273705238,
0x596841674667516c, 0x504e42664b464669, 0x4278306475684334, 0x427565452f41776b, 0x77664a6a70587866}},
ext_ofile = 0xffffffff811a2b50 "/src/NetBSD/act/src/sys/kern/uipc_mbuf.c", ext_nfile = 0xffffffff811a2b50 "/src/NetBSD/act/src/sys/kern/uipc_mbuf.c",
ext_oline = 655, ext_nline = 791}},
MH_databuf = "\000\272\214\365\243\001s\212\f\304z\372\071w\b\000E\000\207\364\060i@\000@\006\000\000\n\310\001\001\n\310f\200\000�\246jB\v\323\342\060\001\341e\200\020\020e}+\000\000\001\001\b\n\000\000\000\355\001\273\275\032\000\000\001\001\b\n\001\273\275\032\000\000\000\355", '\000' <repeats 30 times>, "TKKYC7mIeZCH\r\nmA/5iJNhCn8RpsBUxKlQgFgAhYiFFKfBNP4Chud0xBkwA/EeuBfxXpjJfwP+\032\201\377\377\377\377P+\032\201\377\377\377\377"...}},
M_databuf = '\000' <repeats 16 times>, "\002\210\000\000@\001\000\000\020\000\024\000\250\005\000\000r\004ar", '\000' <repeats 21 times>, "\272\214\365\243\001s\212\f\304z\372\071w\b\000E\000\207\364\060i@\000@\006\000\000\n\310\001\001\n\310f\200\000�\246jB\v\323\342\060\001\341e\200\020\020e}+\000\000\001\001\b\n\000\000\000\355\001\273\275\032\000\000\001\001\b\n\001\273\275\032\000\000\000\355", '\000' <repeats 30 times>, "TKKYC7mIeZCH\r\nmA/5iJNhCn8RpsBUxK"...}}
(gdb)
The bpf code is presumably from isc-dhcpd. Question is why is a freed mbuf passed? All offending buffer have the length of 66 bytes - seems to be a special constellation.
>How-To-Repeat:
Things to note: ixgX interface, client probably a smartphone as ixg1 is connect to the WiFi access point.
>Fix:
not analyzed
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback
State-Changed-By: maxv@NetBSD.org
State-Changed-When: Fri, 27 Apr 2018 19:13:39 +0000
State-Changed-Why:
You may be hitting the m_defrag use-after-free. That's a known problem.
If the following panic is reached, then that's the issue you're having.
I will fix m_defrag soon anyway.
Index: ix_txrx.c
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/ixgbe/ix_txrx.c,v
retrieving revision 1.41
diff -u -r1.41 ix_txrx.c
--- ix_txrx.c 25 Apr 2018 08:46:19 -0000 1.41
+++ ix_txrx.c 27 Apr 2018 19:09:01 -0000
@@ -441,6 +441,7 @@
txr->q_mbuf_defrag_failed++;
return ENOBUFS;
}
+ panic("here's the problem");
m_head = m;
goto retry;
} else {
From: "Maxime Villard" <maxv@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53218 CVS commit: src/sys/kern
Date: Sat, 28 Apr 2018 08:16:15 +0000
Module Name: src
Committed By: maxv
Date: Sat Apr 28 08:16:15 UTC 2018
Modified Files:
src/sys/kern: uipc_mbuf.c
Log Message:
Modify m_defrag, so that it never frees the first mbuf of the chain. While
here use the given 'flags' argument, and not M_DONTWAIT.
We have a problem with several drivers: they poll an mbuf chain from their
queues and call m_defrag on them, but m_defrag could update the mbuf
pointer, so the mbuf in the queue is no longer valid. It is not easy to
fix each driver, because doing pop+push will reorder the queue, and we
don't really want that to happen.
This problem was independently spotted by me, Kengo, Masanobu, and other
people too it seems (perhaps PR/53218).
Now m_defrag leaves the first mbuf in place, and compresses the chain
only starting from the second mbuf in the chain.
It is important not to compress the first mbuf with hacks, because the
storage of this first mbuf may be shared with other mbufs.
To generate a diff of this commit:
cvs rdiff -u -r1.210 -r1.211 src/sys/kern/uipc_mbuf.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/53218 (bpf tripping over FREEd mbufs)
Date: Sat, 28 Apr 2018 10:29:25 +0200
I insert a printf there and you analysis seems to be correct I see
coincidental events:
[ 3656.4355909] m_defag issue
[ 3656.4355909] FREE mbuf m_buf = 0xffffe40479de1c00, m_len = 66,
m_flags = 0x2, m_type = 0x0
Will try your fix next.
From: Maxime Villard <max@m00nbsd.net>
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, kardel@netbsd.org
Cc:
Subject: Re: kern/53218 (bpf tripping over FREEd mbufs)
Date: Tue, 1 May 2018 19:03:17 +0200
So what's up in here? Did you try the patch? Did it fix the use-after-free?
I'm waiting for a feedback before pulling up to 678...
From: Frank Kardel <kardel@netbsd.org>
To: Maxime Villard <max@m00nbsd.net>, gnats-bugs@NetBSD.org,
kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, gnats-admin@netbsd.org
Cc:
Subject: Re: kern/53218 (bpf tripping over FREEd mbufs)
Date: Wed, 2 May 2018 00:13:37 +0200
too many bug to check/verify :-)
This one is now fine. System is now stable.
Thanks for looking into that and fixing it.
Frank
On 05/01/18 19:03, Maxime Villard wrote:
> So what's up in here? Did you try the patch? Did it fix the
> use-after-free?
> I'm waiting for a feedback before pulling up to 678...
State-Changed-From-To: feedback->pending-pullups
State-Changed-By: maxv@NetBSD.org
State-Changed-When: Thu, 03 May 2018 07:03:51 +0000
State-Changed-Why:
[pullup-6 #1547]
[pullup-7 #1602]
[pullup-8 #802]
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53218 CVS commit: [netbsd-6] src/sys/kern
Date: Thu, 3 May 2018 15:00:38 +0000
Module Name: src
Committed By: martin
Date: Thu May 3 15:00:38 UTC 2018
Modified Files:
src/sys/kern [netbsd-6]: uipc_mbuf.c
Log Message:
Pull up following revision(s) (requested by maxv in ticket #1547):
sys/kern/uipc_mbuf.c: revision 1.211 (via patch)
Modify m_defrag, so that it never frees the first mbuf of the chain. While
here use the given 'flags' argument, and not M_DONTWAIT.
We have a problem with several drivers: they poll an mbuf chain from their
queues and call m_defrag on them, but m_defrag could update the mbuf
pointer, so the mbuf in the queue is no longer valid. It is not easy to
fix each driver, because doing pop+push will reorder the queue, and we
don't really want that to happen.
This problem was independently spotted by me, Kengo, Masanobu, and other
people too it seems (perhaps PR/53218).
Now m_defrag leaves the first mbuf in place, and compresses the chain
only starting from the second mbuf in the chain.
It is important not to compress the first mbuf with hacks, because the
storage of this first mbuf may be shared with other mbufs.
To generate a diff of this commit:
cvs rdiff -u -r1.145.2.1 -r1.145.2.2 src/sys/kern/uipc_mbuf.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53218 CVS commit: [netbsd-6-1] src/sys/kern
Date: Thu, 3 May 2018 15:01:20 +0000
Module Name: src
Committed By: martin
Date: Thu May 3 15:01:20 UTC 2018
Modified Files:
src/sys/kern [netbsd-6-1]: uipc_mbuf.c
Log Message:
Pull up following revision(s) (requested by maxv in ticket #1547):
sys/kern/uipc_mbuf.c: revision 1.211 (via patch)
Modify m_defrag, so that it never frees the first mbuf of the chain. While
here use the given 'flags' argument, and not M_DONTWAIT.
We have a problem with several drivers: they poll an mbuf chain from their
queues and call m_defrag on them, but m_defrag could update the mbuf
pointer, so the mbuf in the queue is no longer valid. It is not easy to
fix each driver, because doing pop+push will reorder the queue, and we
don't really want that to happen.
This problem was independently spotted by me, Kengo, Masanobu, and other
people too it seems (perhaps PR/53218).
Now m_defrag leaves the first mbuf in place, and compresses the chain
only starting from the second mbuf in the chain.
It is important not to compress the first mbuf with hacks, because the
storage of this first mbuf may be shared with other mbufs.
To generate a diff of this commit:
cvs rdiff -u -r1.145.2.1 -r1.145.2.1.2.1 src/sys/kern/uipc_mbuf.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53218 CVS commit: [netbsd-6-0] src/sys/kern
Date: Thu, 3 May 2018 15:02:30 +0000
Module Name: src
Committed By: martin
Date: Thu May 3 15:02:30 UTC 2018
Modified Files:
src/sys/kern [netbsd-6-0]: uipc_mbuf.c
Log Message:
Pull up following revision(s) (requested by maxv in ticket #1547):
sys/kern/uipc_mbuf.c: revision 1.211 (via patch)
Modify m_defrag, so that it never frees the first mbuf of the chain. While
here use the given 'flags' argument, and not M_DONTWAIT.
We have a problem with several drivers: they poll an mbuf chain from their
queues and call m_defrag on them, but m_defrag could update the mbuf
pointer, so the mbuf in the queue is no longer valid. It is not easy to
fix each driver, because doing pop+push will reorder the queue, and we
don't really want that to happen.
This problem was independently spotted by me, Kengo, Masanobu, and other
people too it seems (perhaps PR/53218).
Now m_defrag leaves the first mbuf in place, and compresses the chain
only starting from the second mbuf in the chain.
It is important not to compress the first mbuf with hacks, because the
storage of this first mbuf may be shared with other mbufs.
To generate a diff of this commit:
cvs rdiff -u -r1.145 -r1.145.6.1 src/sys/kern/uipc_mbuf.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53218 CVS commit: [netbsd-7] src/sys/kern
Date: Thu, 3 May 2018 15:13:36 +0000
Module Name: src
Committed By: martin
Date: Thu May 3 15:13:36 UTC 2018
Modified Files:
src/sys/kern [netbsd-7]: uipc_mbuf.c
Log Message:
Pull up following revision(s) (requested by maxv in ticket #1602):
sys/kern/uipc_mbuf.c: revision 1.211 (via patch)
Modify m_defrag, so that it never frees the first mbuf of the chain. While
here use the given 'flags' argument, and not M_DONTWAIT.
We have a problem with several drivers: they poll an mbuf chain from their
queues and call m_defrag on them, but m_defrag could update the mbuf
pointer, so the mbuf in the queue is no longer valid. It is not easy to
fix each driver, because doing pop+push will reorder the queue, and we
don't really want that to happen.
This problem was independently spotted by me, Kengo, Masanobu, and other
people too it seems (perhaps PR/53218).
Now m_defrag leaves the first mbuf in place, and compresses the chain
only starting from the second mbuf in the chain.
It is important not to compress the first mbuf with hacks, because the
storage of this first mbuf may be shared with other mbufs.
To generate a diff of this commit:
cvs rdiff -u -r1.158.4.3 -r1.158.4.4 src/sys/kern/uipc_mbuf.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53218 CVS commit: [netbsd-7-1] src/sys/kern
Date: Thu, 3 May 2018 15:14:48 +0000
Module Name: src
Committed By: martin
Date: Thu May 3 15:14:48 UTC 2018
Modified Files:
src/sys/kern [netbsd-7-1]: uipc_mbuf.c
Log Message:
Pull up following revision(s) (requested by maxv in ticket #1602):
sys/kern/uipc_mbuf.c: revision 1.211 (via patch)
Modify m_defrag, so that it never frees the first mbuf of the chain. While
here use the given 'flags' argument, and not M_DONTWAIT.
We have a problem with several drivers: they poll an mbuf chain from their
queues and call m_defrag on them, but m_defrag could update the mbuf
pointer, so the mbuf in the queue is no longer valid. It is not easy to
fix each driver, because doing pop+push will reorder the queue, and we
don't really want that to happen.
This problem was independently spotted by me, Kengo, Masanobu, and other
people too it seems (perhaps PR/53218).
Now m_defrag leaves the first mbuf in place, and compresses the chain
only starting from the second mbuf in the chain.
It is important not to compress the first mbuf with hacks, because the
storage of this first mbuf may be shared with other mbufs.
To generate a diff of this commit:
cvs rdiff -u -r1.158.4.1.6.2 -r1.158.4.1.6.3 src/sys/kern/uipc_mbuf.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53218 CVS commit: [netbsd-8] src/sys/kern
Date: Sun, 6 May 2018 09:20:43 +0000
Module Name: src
Committed By: martin
Date: Sun May 6 09:20:43 UTC 2018
Modified Files:
src/sys/kern [netbsd-8]: uipc_mbuf.c
Log Message:
Pull up following revision(s) (requested by maxv in ticket #802):
sys/kern/uipc_mbuf.c: revision 1.211 (via patch)
Modify m_defrag, so that it never frees the first mbuf of the chain. While
here use the given 'flags' argument, and not M_DONTWAIT.
We have a problem with several drivers: they poll an mbuf chain from their
queues and call m_defrag on them, but m_defrag could update the mbuf
pointer, so the mbuf in the queue is no longer valid. It is not easy to
fix each driver, because doing pop+push will reorder the queue, and we
don't really want that to happen.
This problem was independently spotted by me, Kengo, Masanobu, and other
people too it seems (perhaps PR/53218).
Now m_defrag leaves the first mbuf in place, and compresses the chain
only starting from the second mbuf in the chain.
It is important not to compress the first mbuf with hacks, because the
storage of this first mbuf may be shared with other mbufs.
To generate a diff of this commit:
cvs rdiff -u -r1.172.6.3 -r1.172.6.4 src/sys/kern/uipc_mbuf.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->closed
State-Changed-By: maxv@NetBSD.org
State-Changed-When: Sun, 06 May 2018 10:35:08 +0000
State-Changed-Why:
pullups done
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53218 CVS commit: [netbsd-7-0] src/sys/kern
Date: Tue, 15 May 2018 04:48:16 +0000
Module Name: src
Committed By: martin
Date: Tue May 15 04:48:16 UTC 2018
Modified Files:
src/sys/kern [netbsd-7-0]: uipc_mbuf.c
Log Message:
Pull up following revision(s) (requested by maxv in ticket #1602):
sys/kern/uipc_mbuf.c: revision 1.211 (via patch)
Modify m_defrag, so that it never frees the first mbuf of the chain. While
here use the given 'flags' argument, and not M_DONTWAIT.
We have a problem with several drivers: they poll an mbuf chain from their
queues and call m_defrag on them, but m_defrag could update the mbuf
pointer, so the mbuf in the queue is no longer valid. It is not easy to
fix each driver, because doing pop+push will reorder the queue, and we
don't really want that to happen.
This problem was independently spotted by me, Kengo, Masanobu, and other
people too it seems (perhaps PR/53218).
Now m_defrag leaves the first mbuf in place, and compresses the chain
only starting from the second mbuf in the chain.
It is important not to compress the first mbuf with hacks, because the
storage of this first mbuf may be shared with other mbufs.
To generate a diff of this commit:
cvs rdiff -u -r1.158.4.1.2.2 -r1.158.4.1.2.3 src/sys/kern/uipc_mbuf.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home