Date: Thu, 24 Feb 2005 17:32:18 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c src/sys/sys mbuf.h Message-ID: <20050224172727.T9200@odysseus.silby.com> In-Reply-To: <Pine.NEB.3.96L.1050224202238.23622A-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1050224202238.23622A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Feb 2005, Robert Watson wrote:
> Sorry, I should have been more specific. A patch is attached. Basically,
> 'm_head' can be modified, but on failure, the caller's version of m_head
> isn't modified, as it's passed by value, not reference. So the caller may
> be using the wrong mbuf. In some cases, the caller doesn't know how to
> handle m_head being returned as NULL, and will try to unconditionally
> re-insert the mbuf into the interface queue even if it's NULL. I hadn't
> realized that was a problem when I wrote the below patch, so haven't
> checked if if_rl needs to be tweaked to handle that (most others do need
> to be tweaked, so rl probably does also).
I don't see what you're seeing. If m_defrag fails, rl_encap frees the
mbuf chain, then returns 1. Then, back in rl_start_locked, we have:
if (rl_encap(sc, m_head))
break;
So that failure causes it to break out of the loop.
In the successful m_defrag case, the resulting mbuf is referenced via
RL_CUR_TXMBUF(sc), so there's no need to pass m_head back in that case
either.
What's the problem?
Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050224172727.T9200>