Or cluster allocation failed, and only the mbuf was used.
Sent from my iPhone
On Nov 17, 2012, at 1:31 PM, Robert Watson <rwat...@freebsd.org> wrote:
> Panics along these lines often occur if there is a concurrency bug in a
> device driver such that it modifies an mbuf after dispatching to the network
> stack. E.g., by freeing it, reusing it, an errant dereference, etc. Not
> guaranteed, but that is where I'd start.
>
> Robert
>
> On Sat, 17 Nov 2012, Adrian Chadd wrote:
>
>> Check what mtod() is doing.
>>
>> mbuf.h:#define mtod(m, t) ((t)((m)->m_data))
>>
>> .. so if m->m_data is NULL, bam.
>>
>> The question is why is m_data NULL here. Someone mbuf cluey is going
>> to have to answer that. I don't know whether the MH_dat stuff is being
>> treated as valid but m_data isn't being updated, or something.
>>
>>
>> Adrian
>>
>> On 17 November 2012 10:13, Ian FREISLICH <i...@clue.co.za> wrote:
>>> Adrian Chadd wrote:
>>>> It's a NULL ponter deref. This is my line 484 in if_ethersubr.c:
>>>>
>>>> eh = mtod(m, struct ether_header *);
>>>>
>>>>
>>>> .. if that's yours, see if eh is NULL?
>>>
>>> (kgdb) frame 7
>>> #7 0xffffffff8050f534 in ether_nh_input (m=0xfffffe012521e700)
>>> at /usr/src/sys/net/if_ethersubr.c:484
>>> 484 eh = mtod(m, struct ether_header *);
>>> (kgdb) print eh
>>> No symbol "eh" in current context.
>>> (kgdb) print *m
>>> $2 = {m_hdr = {mh_next = 0x100000000000000, mh_nextpkt = 0x10000000000,
>>> mh_data = 0x0, mh_len = 60, mh_flags = 4259842, mh_type = 0,
>>> pad = "\000\000\000\000\000"}, M_dat = {MH = {MH_pkthdr = {
>>> rcvif = 0xfffffe000a1c2000, header = 0xffffffff, len = 60, flowid =
>>> 0,
>>> csum_flags = 3840, csum_data = 65535, tso_segsz = 0, PH_vt = {
>>> vt_vtag = 4, vt_nrecs = 4}, tags = {slh_first = 0x3c000000}},
>>> MH_dat = {MH_ext = {
>>> ext_buf = 0x69e5498600000000 <Address 0x69e5498600000000 out of
>>> bounds>, ext_free = 0x10602, ext_arg1 = 0xc000000070000, ext_arg2 = 0x100,
>>> ext_size = 2048, ref_cnt = 0xfffffe0125236d8c, ext_type = 6},
>>> MH_databuf =
>>> "\000\000\000\000\206Iеi\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001юяя\006",
>>> '\0' <repeats 118 times>}},
>>> M_databuf = "\000
>>> \034\n\000юяяяяяя\000\000\000\000<\000\000\000\000\000\000\000\000\017\000\000яя\000\000\000\000\004\000\000\000\000\000\000\000\000<\000\000\000\000\000\000\000\000\206Iеi\002\006\001\000\000\000\000\000\000\000\a\000\000\000\f\000\000\001\000\000\000\000\000\000\000\b\000\000\000\000\000\000\214m#%\001юяя\006",
>>> '\0' <repeats 118 times>}}
>>>
>>>
>>> Ian
>>>
>>> --
>>> Ian Freislich
>>>
>>> _______________________________________________
>>> freebsd-current@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>> _______________________________________________
>> freebsd-current@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
