Date: Fri, 10 Apr 2015 11:33:31 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" Message-ID: <bug-148807-2472-RBouHqNEZ1@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-148807-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-148807-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807 --- Comment #17 from Robert Watson <rwatson@FreeBSD.org> --- sbdrop() performs invariant checks as it tears down a socket buffer on final close -- originally intended to validate a set of values cached by the socket buffer that could (in the presence of a socket-buffer bug) get out of sync with the chain stored there. However, these checks have proven something of a 'canary' for many possible underlying bugs involving mbuf chains and socket buffers. I've seen the panics most frequently in the presence of device-driver concurrency bugs -- e.g., in which a driver makes changes to the mbuf chain after handing the mbuf off to the network stack via netisr, for example, or involving improper freeing of an mbuf by other code while it remains referenced by a socket buffer. Others have spotted them in the presence of other classes of network-stack race conditions -- most involving a failure to have a single thread or object own an mbuf. As such, seeing this panic is a symptom of many possible underlying problems and hence not a specific 'bug' per se. However, as a useful rule of thumb: when I spot this panic, I look first at the device driver to make sure that there is no possible use of mbuf after it is passed as an argument to netisr. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-148807-2472-RBouHqNEZ1>