Re: infinite recursion in m_split()

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Apr 03, 2009 at 06:18:35PM +0200, Manuel Bouyer wrote:
> Well, not so good. The conditions which cause this recursion should not
> happen: If m == m0 (i.e. the loop at the start of m_split0() dind't
> progress), and (m0->m_flags & M_PKTHDR) is true, then we either
> have remain (= m0->m_len in this specific case) <= MHLEN or m0 has
> an external storage. So the recursion happens when something wrong
> already happened. The attached patch gives more details on how we get in
> this situation:
> m 0xc3bae000 m0 0xc3bae000 remain 1444 len_save -4 len0 0 len 0 m_len 1444 
> MHLEN 200
> panic: m_split0
> 
> This mbuf obviously has a cluster attached (gdb on the core dump confirmed),
> yet it doesn't have M_EXT set (the (m->m_flags & M_EXT) goto didn't
> catch it, and gdb on the core dump also confirms). So the mbuf got partially
> updated before m_split() I also guess m0->m_pkthdr.len is not supposed
> to be negative, yet we have len_save as -4 (I've also seen -252 or -260).
> So something is putting wrong values in the mbuf before calling m_split()
> on it, but I don't know where it happens.
> The printf() I added to check for len0 == 0 at the top of m_split()
> fires only once, so I guess when slp->ns_reclen == 0 damage has already
> been done to the associated mbuf; it could be related to this
> specific condition.

I have to retract this; another test showed the printf firing several time
without panic. Now the m_split() with len == 0 could have been from another
place than the NFS code ...
I'll add more instrumentation inside the NFS server code tomorow.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--