From: Peter Staubach <staubach@redhat.com>
To: Joe Korty <joe.korty@ccur.com>
Cc: "Myklebust, Trond" <Trond.Myklebust@netapp.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] NFSv3: cached permissions subset enhancement, v2
Date: Thu, 28 Aug 2008 18:00:26 -0400 [thread overview]
Message-ID: <48B71FFA.9050801@redhat.com> (raw)
In-Reply-To: <20080828205727.GA21880@tsunami.ccur.com>
Joe Korty wrote:
> On Thu, Aug 28, 2008 at 02:28:48PM -0400, Joe Korty wrote:
>
>> On Thu, Aug 28, 2008 at 12:03:47PM -0400, Myklebust, Trond wrote:
>>
>>> This isn't a good solution. The correct thing to do here is to resend
>>> the request for just those permissions that the VFS requested.
>>>
>> Is there any chance that the cached permissions are shared amoung
>> multiple open(2)'s of the same file? If sharing happens then we
>> really need to cache all of MAY_EXEC | MAY_WRITE | MAY_READ, rather
>> than just that subset asked for by the open(2) that happens to
>> be the one filling in the cache.
>>
>> In any case, I've rewritten the patch per the above suggestion, and
>>
>
>
> Hi Trond,
> I've tested the new patch with the test sequence mentioned in the
> original customer bug report, and it seems to work.
It would also be good to pursue getting that NFS server fixed.
It is not protocol compliant. That's not the way that the
ACCESS operation is specified to work. The server explicitly
should not return NFS3ERR_ACCESS when access is denied. The
status portion of the return is supposed to indicate the success
or failure of the ACCESS operation itself, not the access
rights that a process may have w.r.t. a file. The bitmask is
to be used for that.
ps
prev parent reply other threads:[~2008-08-28 22:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-27 14:28 [PATCH] NFSv3: cached permissions subset enhancement Joe Korty
2008-08-28 16:03 ` Myklebust, Trond
2008-08-28 18:28 ` [PATCH] NFSv3: cached permissions subset enhancement, v2 Joe Korty
2008-08-28 20:57 ` Joe Korty
2008-08-28 22:00 ` Peter Staubach [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48B71FFA.9050801@redhat.com \
--to=staubach@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=joe.korty@ccur.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox