Re: possible module refcount leak with auth_gss

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 17, 2008 at 02:54:11PM -0500, Trond Myklebust wrote:
> On Wed, 2008-12-17 at 14:41 -0500, J. Bruce Fields wrote:
> > It looks like the CRED_UPTODATE is just being used as a signal to decide
> > whether the PROC_DESTROY has already been sent; the test_and_clear_bit
> > ensures that the null call is made just once.  Maybe a separate flag
> > would be simpler.
> 
> Just make a separate gss_destroy_cred() which doesn't call
> gss_destroying_context() and stick it into gss_nullops.

Lost you there.  So you're thinking the current end of
gss_destroy_cred():

	rcu_assign_pointer(gss_cred->gc_ctx, NULL);
	call_rcu(&cred->cr_rcu, gss_free_cred_callback);
	if (ctx)
		gss_put_ctx(ctx);
	kref_put(&gss_auth->kref,
	gss_free_callback);

should go into a separate gss_nullops.crdestroy, and the real work of
gss_destroying_context() (rpc_call_null, etc.) should be done
unconditionally?

(And presumably the rpc code already ensures that ->crdestroy is called
exactly once?)

OK, makes sense.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux