Re: MPSAFE fxp m_pkthdr not valid

From: Maxime Henrion <mux_at_freebsd.org>
Date: Fri, 4 Apr 2003 14:28:42 +0200
Nate Lawson wrote:
> I have gotten fxp running with MPSAFE and did a large scp transfer.  It
> ran for a few minutes and then paniced.  It was trap 12 (page fault) at
> address 0x24.  Here is where it crashed:
> 
> fxp_start+0xcc
> 0xc0194a4c is in fxp_start (../../../dev/fxp/if_fxp.c:1263).
> 1258                     * been computed and stored in the checksum field
> 1259                     * in the TCP header. The stack should have
> 1260                     * already done this for us.
> 1261                     */
> 1262    
> 1263                    if (mb_head->m_pkthdr.csum_flags) {
> 1264                            if (mb_head->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
> 1265                                    txp->tx_cb->ipcb_ip_activation_high =
> 1266                                       FXP_IPCB_HARDWAREPARSING_ENABLE;
> 1267                                    txp->tx_cb->ipcb_ip_schedule =
> 
> The deref of mb_head->m_pkthdr is invalid.  Note that my fxp_intr function
> acquires the fxp lock right away so this shouldn't be a race in fxp.

Since fxp_start() will usually be called by ether_output(), I don't see
how acquiring the lock in fxp_intr() can protect you from such a race.
You need to acquire the lock in fxp_start() before touching the
interface queue, otherwise it may be preempted by an interrupt and this
will lead to a race if fxp_intr() ends up calling fxp_start().  It really
looks like that's what happened.

Cheers,
Maxime
Received on Fri Apr 04 2003 - 02:28:42 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:02 UTC