[Bug 283426] panic in sbappendaddr_locked()

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283426

Bjoern A. Zeeb <bz@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bz@FreeBSD.org

--- Comment #6 from Bjoern A. Zeeb <bz@FreeBSD.org> ---
May I have a suggestion:  no matter what, can we please fix the panic message
in stable/14 directly if this no longer applies to main to at least print m0 %p
and some of the mbuf flags;  Seems this wasn't done in 2014 but would have
probably answered half of the questions here and now.



The iwm rx ring is populated from:
   m = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, IWM_RBUF_SIZE);

And according to the offsets (line numbers) what is passed up comes out of:
   5321                          * We need to start m_copym() at offset 0, to
get the
   5322                          * M_PKTHDR flag preserved.
   5323                          */
   5324                         m1 = m_copym(m, 0, M_COPYALL, M_NOWAIT);
   5325                         if (m1) {
   5326                                 if (iwm_rx_mpdu(sc, m1, offset,
stolen))

So given we assume to have a copy (reference count increased) with M_PKTHDR the
question then is where in the stack up could we lose this?

ip_input (at least on releng/14.2) does: M_ASSERTPKTHDR() but that's likely
compiled out on the release.

Assuming we pass that the next question would be: IPsec?  Firewall?

I don't see much else in the path to lose the M_PKTHDR.

The only other difference between (likely 14.1? and 14.2) there is that I moved
the epoch from the driver into net80211 but that should not have an effect on
that mbuf.

-- 
You are receiving this mail because:
You are the assignee for the bug.