cvs commit: src/sys/net if_ethersubr.c

[Bernd Walter]

On Tue, Dec 12, 2006 at 03:44:32PM +0200, John Hay wrote:
> On Tue, Dec 12, 2006 at 02:13:34PM +0100, Bernd Walter wrote:
> > On Fri, Dec 08, 2006 at 10:36:46AM +0000, Luigi Rizzo wrote:
> > > luigi       2006-12-08 10:36:45 UTC
> > > 
> > >   FreeBSD src repository
> > > 
> > >   Modified files:
> > >     sys/net              if_ethersubr.c 
> > >   Log:
> > >   Fix an oscure bug triggered by a recent change in kern_socket.c.
> > >   The symptoms were that outgoing DHCP requests for diskless kernels
> > >   had the IP header corrupt. After long investigations, the source of
> > >   the problem was found in ether_output() - for SIMPLEX interfaces
> > >   and broadcast traffic, a copy of the packet is passed back to the kernel
> > >   through if_simloop(). However if_simloop() modifies the mbuf, while
> > >   the copy obtained through m_copym() is a readonly one.
> > >   
> > >   The bug has been there forever, but it has been triggered only recently
> > >   by a change in sosend_dgram() which passed down mbufs with sufficient
> > >   space to prepend the header.
> > >   
> > >   This fix is trivial - use m_dup() instead of m_copy() to create
> > >   the copy. As an alternative, we could try and modify if_simloop()
> > >   to play safely with readonly mbufs, but i don't think it is worthwhile
> > >   because 1) this is a relatively infrequent code path so we do not need
> > >   to worry too much about performance, and 2) the cost of doing an
> > >   extra m_pullup in if_simloop() is probably the same as doing the
> > >   copy of the cluster, anyways.
> > 
> > This change produces an alignment panic on arm.
> > Reverting it gets my system back to live.
> > 
> > Sending DHCP Discover packet from interface ate0 (00:0e:42:02:00:21)
> > Fatal kernel mode data abort: 'Alignment Fault 3'
> > trapframe: 0xc529fd98
> > FSR=000000f3, FAR=c08e181e, spsr=20000013
> > r0 =c08a2e00, r1 =c529fdec, r2 =00000045, r3 =000005d0
> > r4 =c08e180e, r5 =c01eb8a0, r6 =00000014, r7 =00000000
> > r8 =00000000, r9 =c01fb9ac, r10=c079acb8, r11=c529fe10
> > r12=c08a2e00, ssp=c529fde4, slr=c00d2670, pc =c00e2afc
> > 
> > [thread pid 11 tid 100004 ]
> > Stopped at      ip_input+0x9c:  ldr     r1, [r4, #0x010]
> > 
> 
> Interesting, before this commit my Gateworks Xscale arm did panic, but
> this commit fixed the panic. This is what the panic looked like:
> 
> #####################################################################
> Sending DHCP Discover packet from interface npe0 (00:d0:12:02:87:11)
> Fatal kernel mode prefetch abort at 0x00000080
> trapframe: 0xc567ce08, spsr=60000013
> r0 =600000d3, r1 =60000013, r2 =000000c0, r3 =80000020
> r4 =c0b86c40, r5 =c0b7b7c0, r6 =c567ceac, r7 =c042b634
> r8 =00000000, r9 =00000000, r10=c0b85498, r11=c567ce68
> r12=c567ce54, ssp=c567ce54, slr=c041fd64, pc =00000080
> 
> [thread pid 13 tid 100002 ]
> Stopped at      0x80:   address 0x80 is invalid
> *** error reading from address 80 ***
> db>
> #####################################################################

In my case it's an AT91RM9200 based system.
Unfortunately your trap has no valid code address :(

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd at bwct.de           info at bwct.de            support at fizon.de