Re: nfsd bugfixes

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Nov 13, 2007 at 09:35:01AM +1100, Neil Brown wrote:
> 
> (CC: trimmed - as Bruce says: separate discussion)
> 
> On Monday November 12, bfields@fieldses.org wrote:
> > On Tue, Nov 13, 2007 at 09:08:42AM +1100, Neil Brown wrote:
> > > Calling nfsd_setuser an extra time does open us up for a very tiny
> > > possibility of an ENOMEM at an awkward time.
> > 
> > Hm.  Could you give an example of possible consequences?
> 
> Just that you could get an ENOMEM in the middle of a NFSv4 COMPOUND.
> I guess that should result in NFSERR_RESOURCE and we just hope the
> client is able to cope and resend the remainder of the compound.
> Though looking at the code, ENOMEM becomes nfserr_dropit... does that
> mean the we would drop the whole request and the client would need to
> resend, possibly duplicating non-idempotent portions?

Yeah, OK, that's another one for my list of compound processing problems
to worry about.  (Others:

	- a deferral for an export upcall can similarly lead to
	  incorrect behavior on nonidempotent operations; if we could
	  fix this we could also eliminate the nfs4idmap.c special case,
	  which would probably enable some other cleanup.  I've made a
	  couple half-hearted attempts to fix this but don't have
	  anything finished yet.

	- We've still got the reply cache turned off for nfsv4!  I think
	  it was originally turned off just because whoever did it
	  didn't want to figure out which compounds to cache.  That's
	  probably not hard to fix, but last I checked I didn't think
	  our reply cache actually helped much in the tcp case (the only
	  case we care about).  So that needs to be fixed first.  I've
	  done no work on this yet.

)--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/