On 08/15/2011 05:25 PM, J. Bruce Fields wrote: > On Mon, Aug 15, 2011 at 09:03:30AM -0700, Myklebust, Trond wrote: >>> -----Original Message----- >>> From: J. Bruce Fields [mailto:bfields@xxxxxxxxxxxx] >>> How is the client supposed to handle opens of device special files? >> On >>> a 3.1-rc1-based client to a linux server over v4.0 I'm seeing it try >> an >>> OPEN call and failing when it gets an INVAL return. >>> >>> This looks like bogus client behavior (OPEN should fail on such >> files), >>> unless the server has the error return wrong and the client's using an >>> OPEN error to recover. >>> >>> If I first stat the device and then open it then it works as expected >>> (the client does an open of the local device). >>> >>> I'm a bit annoyed at myself as I have a feeling we've discussed this >>> before but I can't find a reference now. >> >> Hmm... NFS4ERR_INVAL means 'invalid argument', which is not the case >> here; all the arguments that the client is passing to the server are >> valid, however the file cannot be opened because the pathname resolves >> on the server to a file of the wrong type. >> >> I can't see any other error definition that is "obviously correct", but >> it looks to me as if NFS4ERR_SYMLINK might be the closest thing. One >> reason is the dot-x file defines NFS4ERR_SYMLINK as meaning "should be >> file/directory". The other reason is that NFS4ERR_SYMLINK should >> _always_ trigger the correct behaviour on a client: a fresh lookup of >> the component. > > Confirmed the fix; I'll apply. Confirmed! The following open now works with all NFS versions: int main (void) { int fd; char buf[20]; size_t nbytes; ssize_t bytes_read; nbytes = sizeof(buf); fd = open("/mnt/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK); if (fd < 0) { perror("open"); exit(1); } bytes_read = read(fd, buf, nbytes); return 0; } Thanks! steved. > > But that's tricky--we should be document it for other server > implementers if it's the right thing to do (working group list cc'd). > > --b. > > commit 3d83c016da8652f30dcac372772b67d68f33bfbd > Author: J. Bruce Fields <bfields@xxxxxxxxxx> > Date: Mon Aug 15 16:55:02 2011 -0400 > > nfsd4: return nfserr_symlink on v4 OPEN of non-regular file > > Without this, an attempt to open a device special file without first > stat'ing it will fail. > > Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxx> > > diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c > index 90c6aa6..cc8eb8d 100644 > --- a/fs/nfsd/nfsfh.c > +++ b/fs/nfsd/nfsfh.c > @@ -69,6 +69,17 @@ nfsd_mode_check(struct svc_rqst *rqstp, umode_t mode, int type) > return nfserr_notdir; > else if ((mode & S_IFMT) == S_IFDIR) > return nfserr_isdir; > + /* > + * err_symlink is our catch-all error in the v4 case; this > + * looks odd, but: > + * - the comment next to ERR_SYMLINK in file is > + * "should be file/directory" > + * - we happen to know this will cause the linux v4 > + * client to do the right thing on attempts to open > + * something other than a regular file: > + */ > + else if (rqstp->rq_vers == 4) > + return nfserr_symlink; > else > return nfserr_inval; > } -- 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
