Re: netisr panic?

Or cluster allocation failed, and only the mbuf was used.

Sent from my iPhone

On Nov 17, 2012, at 1:31 PM, Robert Watson <rwatson_at_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 <ianf_at_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_at_freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> _______________________________________________
> freebsd-net_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe_at_freebsd.org"