On Wed, Dec 17, 2008 at 02:34:58PM -0500, Jeff Layton wrote: > On Wed, 17 Dec 2008 14:20:47 -0500 > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > We certainly shouldn't be really refreshing the cred--that'd end up > > creating a new gss context when what we're trying to do is destroy one. > > So leaving cr_ops set to gss_credops() doesn't sound right. > > > > Maybe that gss_refresh_null() should just return 0 and pretend the > > cred's fine, instead of returning -EACCES? > > > > Possibly -- it does look like this is the only place that those credops > are used. > > What's the reasoning behind clearing the RPCAUTH_CRED_UPTODATE bit > here? If we don't want to refresh the cred, would it be better to just > leave it set? 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. This is Trond's code, so he should probably comment. --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
