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>