Date: Fri, 4 Apr 2003 14:28:42 +0200 From: Maxime Henrion <mux@freebsd.org> To: Nate Lawson <nate@root.org> Cc: current@freebsd.org Subject: Re: MPSAFE fxp m_pkthdr not valid Message-ID: <20030404122842.GP1750@elvis.mu.org> In-Reply-To: <Pine.BSF.4.21.0304032356590.15815-100000@root.org> References: <Pine.BSF.4.21.0304032356590.15815-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030404122842.GP1750>