> On Wed, Jun 1, 2016 at 4:41 PM, Trond Myklebust > <trondmy@xxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
