From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Olga Kornievskaia'" <aglo@umich.edu>,
"'Trond Myklebust'" <trondmy@primarydata.com>
Cc: "'linux-nfs'" <linux-nfs@vger.kernel.org>
Subject: RE: open_downgrade use
Date: Wed, 1 Jun 2016 15:10:18 -0700 [thread overview]
Message-ID: <061c01d1bc52$628e05f0$27aa11d0$@mindspring.com> (raw)
In-Reply-To: <CAN-5tyEdttEMqepHWmd-KgUcH-azbnko4QJsVuwQha=GSVgzoA@mail.gmail.com>
> On Wed, Jun 1, 2016 at 4:41 PM, Trond Myklebust
> <trondmy@primarydata.com> wrote:
> > You are misreading what I wrote. Your test should indeed give rise to
> > an OPEN_DOWNGRADE (unless there is a delegation involved). The code
> > that was misbehaving and that was fixed by the patch was triggering an
> > OPEN_DOWNGRADE from a stateid that had only been opened for RW.
>
> I see. With this patch, the upstream code no longer sends an
> OPEN_DOWNGRADE. I will investigate why then as it seems like a bug.
Does the client send an open for the read only? If not, per spec, having opened read/write, you can't downgrade to read only.
The server should allow the 2nd open for read only as an "upgrade" (which won't actually do anything, except allow the subsequent downgrade to read only).
Such a scenario should be allowed by Ganesha, though my algorithm isn't perfect, when downgrading to read only, we don't "forget" that the file had been opened read/write, so Ganesha would allow the following sequence:
Open read only
Open write only (upgrades to read/write)
Downgrade to read only
Open read/write (upgrades to read/write)
Downgrade to write only
That last downgrade should be rejected per the RFC.
Frank
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
next prev parent reply other threads:[~2016-06-01 22:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-01 20:31 open_downgrade use Olga Kornievskaia
2016-06-01 20:41 ` Trond Myklebust
2016-06-01 20:59 ` Olga Kornievskaia
2016-06-01 22:10 ` Frank Filz [this message]
2016-06-02 19:48 ` Olga Kornievskaia
2016-06-07 14:26 ` Olga Kornievskaia
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='061c01d1bc52$628e05f0$27aa11d0$@mindspring.com' \
--to=ffilzlnx@mindspring.com \
--cc=aglo@umich.edu \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@primarydata.com \
/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;
as well as URLs for NNTP newsgroup(s).