Date: Thu, 13 Oct 2016 17:55:40 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT) Message-ID: <bug-148807-2472-0x0abu8GPy@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 #35 from slw@zxy.spb.ru --- (In reply to Hiren Panchasara from comment #34) > which value of 'm' should I trust? is it null in frame #22 or not? it seems like null in the frames above it also. Š—artially. ether_input call with m set to 0xfffff8014eee7600 (and this is first m for next invocation of further functions), do one (or more, w/ different m, need access to vmcore by kgdb and analyse 0xfffff8014eee7600 for answer) iteration w/ and call netisr_dispatch with passed m as second argument (in %rsi register). All next invocation can don't preserve %rsi (or %rdx in case of m passed as 3'th argument) and backtrace can incorrectly decode arguments call. Just realyty check: frame #19, ether_input_internal (ifp=<optimized out>, m=0x0), line 483: if (m->m_len < ETHER_HDR_LEN) { MUST occur kernel panic if m realy NULL. This is just incorrect decoding of arguments. -- 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-0x0abu8GPy>