From: Christoph Hellwig <hch@lst.de>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Christoph Hellwig <hch@lst.de>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 5/6] nfsd: take struct file setup fully into nfs4_preprocess_stateid_op
Date: Wed, 29 Apr 2015 15:11:48 +0200 [thread overview]
Message-ID: <20150429131148.GA3381@lst.de> (raw)
In-Reply-To: <20150428204455.GC16090@fieldses.org>
On Tue, Apr 28, 2015 at 04:44:55PM -0400, J. Bruce Fields wrote:
> This causes a failure on pynfs OPEN23b.
I've once again tried to run pynfs, but I'm still errors out with weird
python backtraces for any of the examples from the readme I copy
and pasted, e.g.:
root@vm:~/pynfs/nfs4.0# ./testserver.py 127.0.0.1:/mnt/test --maketree all
Initialization failed, no tests run.
Traceback (most recent call last):
File "./testserver.py", line 379, in <module>
main()
File "./testserver.py", line 342, in main
env.init()
File "/root/pynfs/nfs4.0/servertests/environment.py", line 140, in init
self._maketree()
File "/root/pynfs/nfs4.0/servertests/environment.py", line 159, in _maketree
"Could not LOOKUP /%s," % '/'.join(path))
File "/root/pynfs/nfs4.0/servertests/environment.py", line 274, in checklist
raise testmod.FailureException(msg)
testmod.FailureException: Could not LOOKUP /mnt, should return NFS4_OK or NFS4ERR_NOENT, instead got NFS4ERR_PERM
root@vm:~/pynfs/nfs4.1# ./testserver.py 127.0.0.1:/mnt/test --maketree all
Could not find gssapi module, proceeding without
INFO :rpc.poll:got connection from ('127.0.0.1', 37715), assigned to fd=5
INFO :rpc.thread:Called connect(('127.0.0.1', 2049))
INFO :rpc.poll:Adding 6 generated by another thread
INFO :test.env:Created client to 127.0.0.1, 2049
INFO :nfs.client.cb:********************
INFO :nfs.client.cb:Handling CB_NULL
Initialization failed, no tests run.
Traceback (most recent call last):
File "./testserver.py", line 359, in <module>
main()
File "./testserver.py", line 322, in main
env.init()
File "/root/pynfs/nfs4.1/server41tests/environment.py", line 150, in init
self._maketree(sess)
File "/root/pynfs/nfs4.1/server41tests/environment.py", line 166, in _maketree
"LOOKUP /%s," % '/'.join(path))
File "/root/pynfs/nfs4.1/server41tests/environment.py", line 304, in checklist
raise testmod.FailureException(msg)
testmod.FailureException: LOOKUP /mnt, should return NFS4_OK or NFS4ERR_NOENT, instead got NFS4ERR_PERM
> It's doing a READ using a stateid from a write open. We previously
> returned NFS_OK, taking the "may" option from:
>
> http://tools.ietf.org/html/rfc7530#page-111
>
> In the case of READ, the server may perform the corresponding
> check on the access mode, or it may choose to allow READ on
> opens for WRITE only, to accommodate clients whose write
> implementation may unavoidably do reads (e.g., due to buffer
> cache constraints).
>
> OPENMODE might also have been OK, but we're returning SERVERFAULT. I
> guess the old code was passing preprocess_stateid_op without returning a
> file, then relying on a temporary open for the read? Ugh.
Looks like it. I can change it to return an OPENMODE, or we could
make it fall back to a temp read open.
next prev parent reply other threads:[~2015-04-29 13:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-28 13:41 refactor stateid checking and file allocation Christoph Hellwig
2015-04-28 13:41 ` [PATCH 1/6] nfsd: fix the check for confirmed openowner in nfs4_preprocess_stateid_op Christoph Hellwig
2015-04-28 19:12 ` J. Bruce Fields
2015-04-28 13:41 ` [PATCH 2/6] nfsd: remove nfsd_close Christoph Hellwig
2015-04-28 13:41 ` [PATCH 3/6] nfsd: refactor nfs4_preprocess_stateid_op Christoph Hellwig
2015-04-28 13:41 ` [PATCH 4/6] nfsd: clean up raparams handling Christoph Hellwig
2015-04-28 13:41 ` [PATCH 5/6] nfsd: take struct file setup fully into nfs4_preprocess_stateid_op Christoph Hellwig
2015-04-28 20:44 ` J. Bruce Fields
2015-04-28 20:50 ` J. Bruce Fields
2015-04-29 13:11 ` Christoph Hellwig [this message]
2015-04-29 14:16 ` J. Bruce Fields
2015-04-28 13:41 ` [PATCH 6/6] nfsd: drop the file argument to nfsd_write Christoph Hellwig
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=20150429131148.GA3381@lst.de \
--to=hch@lst.de \
--cc=bfields@fieldses.org \
--cc=linux-nfs@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;
as well as URLs for NNTP newsgroup(s).