2008-02-13 00:13:09[permalink] [raw]
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 || entry == 0))
> ...but if nr==0, then I think entry must be 0 as well. So, I'm
> guessing that the server always set value_follows=0 and EOF=0. Is that
> 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...