mbuf leakage with nfs/zfs?

Daniel Braniss danny at cs.huji.ac.il
Fri Mar 5 07:45:48 UTC 2010


> 
> 
> On Tue, 2 Mar 2010, Daniel Braniss wrote:
> 
> >
> > just keep sending insights/pointers and enjoy life
> >
> 
> 
> You could try this patch for sys/rpc/replay.c. Completely untested and
> just typed into email (so don't give it to "patch", just edit the file).
> 
> - try adding these 2 lines just before the end of replay_setreply() in
>    sys/rpc/replay.c:
> 
> -	}
> +	} else if (m)
> +		m_freem(m);
>  	mtx_unlock(&rc->rc_lock);
> }
> 
> It's the only place I can see in replay.c that might leak, rick
> 
this is what I did:
--- a/sys/rpc/replay.c  Mon Mar 01 18:29:54 2010 +0200
+++ b/sys/rpc/replay.c  Fri Mar 05 09:24:17 2010 +0200
@@ -243,6 +243,9 @@
                rce->rce_repbody = m;
                if (m)
                        rc->rc_size += m_length(m, NULL);
+       } else if (m) {
+            printf("free m=%p ...\n", m);
+            m_freem(m);
        }
        mtx_unlock(&rc->rc_lock);
 }

but it didn't help, it's not triggered

Thanks for the explanation on the cache, things are begining to make sense.
If I understand, the reason for this cache is to prevent re-applying an
already performed rpc, which could lead to data corruption

btw, the list of CCs is rather big, so if anyone feels he rather be removed,
please let me know.

cheers,
	danny






More information about the freebsd-fs mailing list