Re: nfsd bug fixes for 3.15

[Trond Myklebust]

On Thu, Apr 24, 2014 at 12:34 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
> On Thu, Apr 24, 2014 at 11:31:16AM -0400, J. Bruce Fields wrote:
>> On Thu, Apr 24, 2014 at 06:51:03AM -0400, Trond Myklebust wrote:
>> > Hi Bruce,
>> >
>> > On Thu, Apr 24, 2014 at 2:25 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
>> > > Please pull the following bug fixes for 3.15 from:
>> > >
>> > >   git://linux-nfs.org/~bfields/linux.git for-3.15
>> > >
>> > > Three small nfsd bugfixes (including one locks.c fix for a bug triggered
>> > > only from nfsd).
>> > >
>> > > Jeff's patches are for long-existing problems that became easier to
>> > > trigger since the addition of vfs delegation support.
>> > >
>> > > --b.
>> > >
>> > > ----------------------------------------------------------------
>> > > J. Bruce Fields (1):
>> > >       Revert "nfsd4: fix nfs4err_resource in 4.1 case"
>> > >
>> >
>> > Wait. Why?
>>
>> Have you changed your mind since our previous discussion, or just
>> forgotten it?  (Or did I screw up and revert the wrong commit?)  See
>>
>>       http://mid.gmane.org/<BAD6904F-A82A-4FBC-807F-16560B2A23E0@xxxxxxxxxxxxxxx>
>>
>> > NFS4ERR_RESOURCE breaks the Linux client.
>>
>> This returns us to pre-3.15 behavior so shouldn't introduce any new
>> breakage.
>>
>> Fundamentally the problem is that we're returning an error in cases that
>> shouldn't succeed, and rather than replacing one incorrect error by
>
> s/shouldn't/should/, apologies!--b.
>
>> another it seemed better to wait for a proper fix.
>>
>> --b.

I really shouldn't try to read my email before 8am (or at least not
before my third espresso). I was confusing this with the
NFS4ERR_STALE_STATEID problem that was merged as part of the same
pull.
Reverting the NFS4ERR_RESOURCE patch is fine.

Apologies,
  Trond

-- 
Trond Myklebust

Linux NFS client maintainer, PrimaryData

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