On Tue, 2008-02-12 at 08:20 -0500, Jeff Layton wrote: > On Fri, 08 Feb 2008 11:13:07 -0500 > Trond Myklebust <[EMAIL PROTECTED]> wrote: > > > > > On Fri, 2008-02-08 at 10:56 -0500, Jeff Layton wrote: > > > > > If it looks like the above, but EOF is 0, then we *do* "goto > > > short_pkt", and that case would be affected by this. But in that case > > > we currently reset EOF to 1. The client won't retry the request. I'm > > > not sure that's what we want to do either... > > > > That is to deal with the afore-mentioned broken server. I'm not > > unwilling to change this (I _hate_ client side fixes for server bugs), > > but it's important to note that there may be consequences if we do. > > Perhaps we can just narrow down this special case so that this server > still works, but we can return a proper error when we get other bogus > packets? We currently have this: > > if (!nr && (entry[0] != 0 || entry[1] == 0)) > > ...but if nr==0, then I think entry[0] must be 0 as well. So, I'm > guessing that the server always set value_follows=0 and EOF=0. Is that > correct? > > If so, what about something like the following patch? This should > hopefully make it so that packets that are badly sized return -EIO, but > the special case you mention should continue to work.
Yup. This looks like it should cover most known cases... Cheers Trond - To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
