On Wed, 2009-03-04 at 20:23 +0100, Piotr Jasiukajtis wrote:
> > ffffff0192255bf8::bufctl
> ADDR BUFADDR TIMESTAMP THREAD CALLER
> ffffff0192255bf8 ffffff0191535ea8 13a7ce2ccd ffffff0007c07c60
> labelalloc+0x2f
> > ffffff0192255bf8::bufctl -v
> ADDR BUFADDR TIMESTAMP THREAD
> CACHE LASTLOG CONTENTS
> ffffff0192255bf8 ffffff0191535ea8 13a7ce2ccd ffffff0007c07c60
> ffffff019131fb20 ffffff0188af8440 0
> kmem_cache_alloc_debug+0x288
> kmem_cache_alloc+0x166
> labelalloc+0x2f
> newcred_from_bslabel+0x23
> tsol_get_pkt_label+0x42a
> ip_input+0x51b
> mac_rx_soft_ring_drain+0xf6
> mac_soft_ring_worker+0x140
> thread_start+8
I think I see what the problem is -- my project's testing uncovered the
same leak.
tsol_get_pkt_label constructs a new cred using "newcred_from_bslabel",
and creates it with a refcount of 1.
it then gets passed to mblk_setcred(), which does a crhold on it,
setting the refcount to 2.
tsol_get_pkt_label never drops the original reference, so that when the
dblk is freed, the cred refcount drops back to 1, and the cred is leaked
and never freed.
it looks like this bug may have been introduced in this recent
changeset:
changeset: 8778:b4169d2ab299
user: Erik Nordmark <[email protected]>
date: Thu Feb 12 08:42:06 2009 -0800
PSARC 2007/670 db_credp update
6619593 Simplify and strengthen db_credp handling
6619596 Add getpeerucred() support to SCTP SOCK_STREAM
I'll file a bug.
- Bill
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
