| Message ID | 20120109132153.2616029.26302.stgit@localhost.localdomain |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Mon, Mar 05, 2012 at 07:08:37PM -0500, Ted Ts'o wrote: > On Mon, Jan 09, 2012 at 02:21:53PM +0100, Bernd Schubert wrote: > > Just rename this variable, as the next patch will add a flag and > > 'access' as variable name would not be correct any more. > > > > Signed-off-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de> > > Acked-by: J. Bruce Fields<bfields@redhat.com> > > --- > > fs/nfsd/vfs.c | 18 ++++++++++-------- > > 1 files changed, 10 insertions(+), 8 deletions(-) > > On Mon, Jan 09, 2012 at 02:21:58PM +0100, Bernd Schubert wrote: > > Use 32-bit or 64-bit llseek() hashes for directory offsets depending on > > the NFS version. NFSv2 gets 32-bit hashes only. > > > > NOTE: This patch got rather complex as Christoph asked to set the > > filp->f_mode flag in the open call or immediatly after dentry_open() > > in nfsd_open() to avoid races. > > Personally I still do not see a reason for that and in my opinion > > FMODE_32BITHASH/FMODE_64BITHASH flags could be set nfsd_readdir(), as it > > follows directly after nfsd_open() without a chance of races. > > > > Signed-off-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de> > > Acked-by: J. Bruce Fields<bfields@redhat.com> > > --- > > fs/nfsd/vfs.c | 15 +++++++++++++-- > > fs/nfsd/vfs.h | 2 ++ > > 2 files changed, 15 insertions(+), 2 deletions(-) > > NFS folks, > > Since Bruce has ack'ed these patches I assume it will be OK if I carry > them in the ext4 tree for merging? (They depend on changes in ext4 > found in the first two patches of these patch series.) Yes, that would be fine. (There may well be some conflict: simplest might be if you can get that pushed out to a stable public branch somewhere, hopefully before the merge window opens, and that'll give me a chance to pull it and handle any merge conflicts. Then as long as your initial pull request goes in early (so that the ext4 changes don't get sucked in with mine), everything works.) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 05, 2012 at 09:08:19PM -0500, J. Bruce Fields wrote: > Yes, that would be fine. > > (There may well be some conflict: simplest might be if you can get that > pushed out to a stable public branch somewhere, hopefully before the > merge window opens, and that'll give me a chance to pull it and handle > any merge conflicts. Are the commits you're worried about on the NFS side already in linux-next? If so, I'll do a quick test merge and see if there are any conflicts. If so, I'll segregate out these patches into a separate pre-merge branch --- and then if you like you could pull them into your branch and we can deal with it that way. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 06, 2012 at 10:18:16AM -0500, Ted Ts'o wrote: > On Mon, Mar 05, 2012 at 09:08:19PM -0500, J. Bruce Fields wrote: > > Yes, that would be fine. > > > > (There may well be some conflict: simplest might be if you can get that > > pushed out to a stable public branch somewhere, hopefully before the > > merge window opens, and that'll give me a chance to pull it and handle > > any merge conflicts. > > Are the commits you're worried about on the NFS side already in > linux-next? No (though there might be some other conflicts there I haven't thought of). > If so, I'll do a quick test merge and see if there are > any conflicts. If so, I'll segregate out these patches into a > separate pre-merge branch --- and then if you like you could pull them > into your branch and we can deal with it that way. That sounds like a good way to do it regardless? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 06, 2012 at 10:28:43AM -0500, J. Bruce Fields wrote: > > If so, I'll do a quick test merge and see if there are > > any conflicts. If so, I'll segregate out these patches into a > > separate pre-merge branch --- and then if you like you could pull them > > into your branch and we can deal with it that way. > > That sounds like a good way to do it regardless? Linus in general doesn't like cross tree merges (or any extraneous merges) unless they are absolutely necessary; but then, he trusts git merges more than many of us do. :-) I've put the the patch series on a separate patch, with a signed tag, at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git nfs-ext4-premerge Can you confirm that you've pulled it into your tree and it's landed in linux-next? I probably won't bother pulling it in mine unless there is definitely a merge conflict that I need to resolve. (I've checked and there do not appear to be any against linux-next as of last night.) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 09, 2012 at 03:51:48PM -0500, Ted Ts'o wrote: > > Linus in general doesn't like cross tree merges (or any extraneous > merges) unless they are absolutely necessary; but then, he trusts git > merges more than many of us do. :-) > > I've put the the patch series on a separate patch, with a signed tag, at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git nfs-ext4-premerge > > Can you confirm that you've pulled it into your tree and it's landed > in linux-next? I probably won't bother pulling it in mine unless > there is definitely a merge conflict that I need to resolve. (I've > checked and there do not appear to be any against linux-next as of > last night.) Ping? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 12, 2012 at 11:09:12AM -0400, Ted Ts'o wrote: > On Fri, Mar 09, 2012 at 03:51:48PM -0500, Ted Ts'o wrote: > > > > Linus in general doesn't like cross tree merges (or any extraneous > > merges) unless they are absolutely necessary; but then, he trusts git > > merges more than many of us do. :-) > > > > I've put the the patch series on a separate patch, with a signed tag, at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git nfs-ext4-premerge > > > > Can you confirm that you've pulled it into your tree and it's landed > > in linux-next? I probably won't bother pulling it in mine unless > > there is definitely a merge conflict that I need to resolve. (I've > > checked and there do not appear to be any against linux-next as of > > last night.) > > Ping? Whoops, sorry. Looks perfect, thanks for handling these! I'm running them through my usual regression tests and then I'll push the result out soon, with a "here's why I'm merging this" comment on the merge commit. (Though I can't see it would trigger Linus's usual back-merge rant anyway, as it's obviously quite targetted, not a case of "oh I think I'll update to -rc5 now".) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 12, 2012 at 11:49:21AM -0400, J. Bruce Fields wrote: > On Mon, Mar 12, 2012 at 11:09:12AM -0400, Ted Ts'o wrote: > > On Fri, Mar 09, 2012 at 03:51:48PM -0500, Ted Ts'o wrote: > > > > > > Linus in general doesn't like cross tree merges (or any extraneous > > > merges) unless they are absolutely necessary; but then, he trusts git > > > merges more than many of us do. :-) > > > > > > I've put the the patch series on a separate patch, with a signed tag, at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git nfs-ext4-premerge > > > > > > Can you confirm that you've pulled it into your tree and it's landed > > > in linux-next? I probably won't bother pulling it in mine unless > > > there is definitely a merge conflict that I need to resolve. (I've > > > checked and there do not appear to be any against linux-next as of > > > last night.) > > > > Ping? > > Whoops, sorry. > > Looks perfect, thanks for handling these! > > I'm running them through my usual regression tests Urgh, I'm seeing a failure on the telldir test (part of the "special" connectathon tests). I haven't looked at what it's trying to do yet. Reproduceable even just on a local filesystem without NFS involved. If someone wants to look at it, you can just do: git clone git://linux-nfs.org/~bfields/cthon04.git cd cthon04 make NFS_TESTDIR=/somewhere_on_an_ext4_fs/TMP ./runtests -s (Or after running that, more specifically, cd /somewhere_on_an_ext4_fs/TMP/ ./telldir ) I'll look at it tomorrow. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 12, 2012 at 06:22:50PM -0400, bfields wrote: > On Mon, Mar 12, 2012 at 11:49:21AM -0400, J. Bruce Fields wrote: > > On Mon, Mar 12, 2012 at 11:09:12AM -0400, Ted Ts'o wrote: > > > On Fri, Mar 09, 2012 at 03:51:48PM -0500, Ted Ts'o wrote: > > > > > > > > Linus in general doesn't like cross tree merges (or any extraneous > > > > merges) unless they are absolutely necessary; but then, he trusts git > > > > merges more than many of us do. :-) > > > > > > > > I've put the the patch series on a separate patch, with a signed tag, at: > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git nfs-ext4-premerge > > > > > > > > Can you confirm that you've pulled it into your tree and it's landed > > > > in linux-next? I probably won't bother pulling it in mine unless > > > > there is definitely a merge conflict that I need to resolve. (I've > > > > checked and there do not appear to be any against linux-next as of > > > > last night.) > > > > > > Ping? > > > > Whoops, sorry. > > > > Looks perfect, thanks for handling these! > > > > I'm running them through my usual regression tests > > Urgh, I'm seeing a failure on the telldir test (part of the "special" > connectathon tests). I haven't looked at what it's trying to do yet. > Reproduceable even just on a local filesystem without NFS involved. If > someone wants to look at it, you can just do: > > git clone git://linux-nfs.org/~bfields/cthon04.git > cd cthon04 > make > NFS_TESTDIR=/somewhere_on_an_ext4_fs/TMP ./runtests -s > > (Or after running that, more specifically, > > cd /somewhere_on_an_ext4_fs/TMP/ > ./telldir > > ) > > I'll look at it tomorrow. Looks like seekdir is just not accepting an offset returned from getdents: openat(AT_FDCWD, "telldir-test", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 getdents(3, {...{d_ino=20386, d_off=5728083968307607285, d_reclen=24, d_name="192"}...} = 4848 lseek(3, 5728083968307607285, SEEK_SET) = -1 EINVAL (Invalid argument) Still investigating. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/13/2012 09:01 PM, J. Bruce Fields wrote: > On Mon, Mar 12, 2012 at 06:22:50PM -0400, bfields wrote: >> On Mon, Mar 12, 2012 at 11:49:21AM -0400, J. Bruce Fields wrote: >>> On Mon, Mar 12, 2012 at 11:09:12AM -0400, Ted Ts'o wrote: >>>> On Fri, Mar 09, 2012 at 03:51:48PM -0500, Ted Ts'o wrote: >>>>> >>>>> Linus in general doesn't like cross tree merges (or any extraneous >>>>> merges) unless they are absolutely necessary; but then, he trusts git >>>>> merges more than many of us do. :-) >>>>> >>>>> I've put the the patch series on a separate patch, with a signed tag, at: >>>>> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git nfs-ext4-premerge >>>>> >>>>> Can you confirm that you've pulled it into your tree and it's landed >>>>> in linux-next? I probably won't bother pulling it in mine unless >>>>> there is definitely a merge conflict that I need to resolve. (I've >>>>> checked and there do not appear to be any against linux-next as of >>>>> last night.) >>>> >>>> Ping? >>> >>> Whoops, sorry. >>> >>> Looks perfect, thanks for handling these! >>> >>> I'm running them through my usual regression tests >> >> Urgh, I'm seeing a failure on the telldir test (part of the "special" >> connectathon tests). I haven't looked at what it's trying to do yet. >> Reproduceable even just on a local filesystem without NFS involved. If >> someone wants to look at it, you can just do: >> >> git clone git://linux-nfs.org/~bfields/cthon04.git >> cd cthon04 >> make >> NFS_TESTDIR=/somewhere_on_an_ext4_fs/TMP ./runtests -s >> >> (Or after running that, more specifically, >> >> cd /somewhere_on_an_ext4_fs/TMP/ >> ./telldir >> >> ) >> >> I'll look at it tomorrow. > > Looks like seekdir is just not accepting an offset returned from > getdents: > > openat(AT_FDCWD, "telldir-test", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 > getdents(3, {...{d_ino=20386, d_off=5728083968307607285, d_reclen=24, d_name="192"}...} = 4848 > lseek(3, 5728083968307607285, SEEK_SET) = -1 EINVAL (Invalid argument) > > Still investigating. Thanks! I'm also just going to work on it (just noticed your mail while on vacation ...). -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 13, 2012 at 09:03:51PM +0100, Bernd Schubert wrote: > On 03/13/2012 09:01 PM, J. Bruce Fields wrote: > >On Mon, Mar 12, 2012 at 06:22:50PM -0400, bfields wrote: > >>On Mon, Mar 12, 2012 at 11:49:21AM -0400, J. Bruce Fields wrote: > >>>On Mon, Mar 12, 2012 at 11:09:12AM -0400, Ted Ts'o wrote: > >>>>On Fri, Mar 09, 2012 at 03:51:48PM -0500, Ted Ts'o wrote: > >>>>> > >>>>>Linus in general doesn't like cross tree merges (or any extraneous > >>>>>merges) unless they are absolutely necessary; but then, he trusts git > >>>>>merges more than many of us do. :-) > >>>>> > >>>>>I've put the the patch series on a separate patch, with a signed tag, at: > >>>>> > >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git nfs-ext4-premerge > >>>>> > >>>>>Can you confirm that you've pulled it into your tree and it's landed > >>>>>in linux-next? I probably won't bother pulling it in mine unless > >>>>>there is definitely a merge conflict that I need to resolve. (I've > >>>>>checked and there do not appear to be any against linux-next as of > >>>>>last night.) > >>>> > >>>>Ping? > >>> > >>>Whoops, sorry. > >>> > >>>Looks perfect, thanks for handling these! > >>> > >>>I'm running them through my usual regression tests > >> > >>Urgh, I'm seeing a failure on the telldir test (part of the "special" > >>connectathon tests). I haven't looked at what it's trying to do yet. > >>Reproduceable even just on a local filesystem without NFS involved. If > >>someone wants to look at it, you can just do: > >> > >> git clone git://linux-nfs.org/~bfields/cthon04.git > >> cd cthon04 > >> make > >> NFS_TESTDIR=/somewhere_on_an_ext4_fs/TMP ./runtests -s > >> > >>(Or after running that, more specifically, > >> > >> cd /somewhere_on_an_ext4_fs/TMP/ > >> ./telldir > >> > >>) > >> > >>I'll look at it tomorrow. > > > >Looks like seekdir is just not accepting an offset returned from > >getdents: > > > > openat(AT_FDCWD, "telldir-test", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 > > getdents(3, {...{d_ino=20386, d_off=5728083968307607285, d_reclen=24, d_name="192"}...} = 4848 > > lseek(3, 5728083968307607285, SEEK_SET) = -1 EINVAL (Invalid argument) > > > >Still investigating. > > Thanks! I'm also just going to work on it (just noticed your mail > while on vacation ...). OK, good. You can probably figure this out faster than me.... --b. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/13/2012 09:34 PM, J. Bruce Fields wrote: > On Tue, Mar 13, 2012 at 09:03:51PM +0100, Bernd Schubert wrote: >> On 03/13/2012 09:01 PM, J. Bruce Fields wrote: >>> On Mon, Mar 12, 2012 at 06:22:50PM -0400, bfields wrote: >>>> On Mon, Mar 12, 2012 at 11:49:21AM -0400, J. Bruce Fields wrote: >>>>> On Mon, Mar 12, 2012 at 11:09:12AM -0400, Ted Ts'o wrote: >>>>>> On Fri, Mar 09, 2012 at 03:51:48PM -0500, Ted Ts'o wrote: >>>>>>> >>>>>>> Linus in general doesn't like cross tree merges (or any extraneous >>>>>>> merges) unless they are absolutely necessary; but then, he trusts git >>>>>>> merges more than many of us do. :-) >>>>>>> >>>>>>> I've put the the patch series on a separate patch, with a signed tag, at: >>>>>>> >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git nfs-ext4-premerge >>>>>>> >>>>>>> Can you confirm that you've pulled it into your tree and it's landed >>>>>>> in linux-next? I probably won't bother pulling it in mine unless >>>>>>> there is definitely a merge conflict that I need to resolve. (I've >>>>>>> checked and there do not appear to be any against linux-next as of >>>>>>> last night.) >>>>>> >>>>>> Ping? >>>>> >>>>> Whoops, sorry. >>>>> >>>>> Looks perfect, thanks for handling these! >>>>> >>>>> I'm running them through my usual regression tests >>>> >>>> Urgh, I'm seeing a failure on the telldir test (part of the "special" >>>> connectathon tests). I haven't looked at what it's trying to do yet. >>>> Reproduceable even just on a local filesystem without NFS involved. If >>>> someone wants to look at it, you can just do: >>>> >>>> git clone git://linux-nfs.org/~bfields/cthon04.git >>>> cd cthon04 >>>> make >>>> NFS_TESTDIR=/somewhere_on_an_ext4_fs/TMP ./runtests -s >>>> >>>> (Or after running that, more specifically, >>>> >>>> cd /somewhere_on_an_ext4_fs/TMP/ >>>> ./telldir >>>> >>>> ) >>>> >>>> I'll look at it tomorrow. >>> >>> Looks like seekdir is just not accepting an offset returned from >>> getdents: >>> >>> openat(AT_FDCWD, "telldir-test", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 >>> getdents(3, {...{d_ino=20386, d_off=5728083968307607285, d_reclen=24, d_name="192"}...} = 4848 >>> lseek(3, 5728083968307607285, SEEK_SET) = -1 EINVAL (Invalid argument) >>> >>> Still investigating. >> >> Thanks! I'm also just going to work on it (just noticed your mail >> while on vacation ...). > > OK, good. You can probably figure this out faster than me.... > Hmm, there must have gone something wrong on merging, my own test also fails http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/test_seekdir/ (Sorry, it does not say 'failure', but one needs to compare the file names and telldir-offset numbers) I think I will continue in the morning as its already 1 a.m. here. Cheers, Bernd -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 13, 2012 at 04:34:46PM -0400, J. Bruce Fields wrote: > > > > Thanks! I'm also just going to work on it (just noticed your mail > > while on vacation ...). Brend, thanks!! Bruce, random question --- do you know what the copyright and licensing terms are for the connectathon test suite? It occurs to me that it might be good to get some of these tests into xfstests, given that you mentioned that the telldir test was failing even when run on a local file system. That says to me this is a good file system level test that we should try to get into xfstests if possible. Getting it into xfstests would also tend to reduce the chance of regressions, since I always run xfstests before I submit patches (and in fact I did run xfstests before sending you a pull request Bernd's patches --- and I'm glad your testing caught the problem when mine didn't!) Thanks, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 13, 2012 at 05:10:09PM -0400, Ted Ts'o wrote: > On Tue, Mar 13, 2012 at 04:34:46PM -0400, J. Bruce Fields wrote: > > > > > > Thanks! I'm also just going to work on it (just noticed your mail > > > while on vacation ...). > > Brend, thanks!! > > Bruce, random question --- do you know what the copyright and > licensing terms are for the connectathon test suite? Alas. Nobody does! I'ts unlikely there's any owner who would care enough to make a fuss--so we keep using the tests, but they don't really get any love. It's one of those annoyances we argue about once a year or so, and then forget till next time. So, maybe one way forward would be to reimplement the connectathon tests for xfstests? --b. > It occurs to me > that it might be good to get some of these tests into xfstests, given > that you mentioned that the telldir test was failing even when run on > a local file system. That says to me this is a good file system level > test that we should try to get into xfstests if possible. > > Getting it into xfstests would also tend to reduce the chance of > regressions, since I always run xfstests before I submit patches (and > in fact I did run xfstests before sending you a pull request Bernd's > patches --- and I'm glad your testing caught the problem when mine > didn't!) > > Thanks, > > - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 13, 2012 at 10:09:05PM +0100, Bernd Schubert wrote: > Hmm, there must have gone something wrong on merging, In that case one approach would be to rebase your last-sent patches on to the same base as Ted's versions, confirm that one still works and the other doesn't, and do a diff.... > my own test > also fails > > http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/test_seekdir/ > > (Sorry, it does not say 'failure', but one needs to compare the file > names and telldir-offset numbers) > > I think I will continue in the morning as its already 1 a.m. here. OK, thanks for following up! --b. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c index d25a723..20fa252 100644 --- a/fs/nfsd/vfs.c +++ b/fs/nfsd/vfs.c @@ -726,12 +726,13 @@ static int nfsd_open_break_lease(struct inode *inode, int access) /* * Open an existing file or directory. - * The access argument indicates the type of open (read/write/lock) + * The may_flags argument indicates the type of open (read/write/lock) + * and additional flags. * N.B. After this call fhp needs an fh_put */ __be32 nfsd_open(struct svc_rqst *rqstp, struct svc_fh *fhp, umode_t type, - int access, struct file **filp) + int may_flags, struct file **filp) { struct dentry *dentry; struct inode *inode; @@ -746,7 +747,7 @@ nfsd_open(struct svc_rqst *rqstp, struct svc_fh *fhp, umode_t type, * and (hopefully) checked permission - so allow OWNER_OVERRIDE * in case a chmod has now revoked permission. */ - err = fh_verify(rqstp, fhp, type, access | NFSD_MAY_OWNER_OVERRIDE); + err = fh_verify(rqstp, fhp, type, may_flags | NFSD_MAY_OWNER_OVERRIDE); if (err) goto out; @@ -757,7 +758,7 @@ nfsd_open(struct svc_rqst *rqstp, struct svc_fh *fhp, umode_t type, * or any access when mandatory locking enabled */ err = nfserr_perm; - if (IS_APPEND(inode) && (access & NFSD_MAY_WRITE)) + if (IS_APPEND(inode) && (may_flags & NFSD_MAY_WRITE)) goto out; /* * We must ignore files (but only files) which might have mandatory @@ -770,12 +771,12 @@ nfsd_open(struct svc_rqst *rqstp, struct svc_fh *fhp, umode_t type, if (!inode->i_fop) goto out; - host_err = nfsd_open_break_lease(inode, access); + host_err = nfsd_open_break_lease(inode, may_flags); if (host_err) /* NOMEM or WOULDBLOCK */ goto out_nfserr; - if (access & NFSD_MAY_WRITE) { - if (access & NFSD_MAY_READ) + if (may_flags & NFSD_MAY_WRITE) { + if (may_flags & NFSD_MAY_READ) flags = O_RDWR|O_LARGEFILE; else flags = O_WRONLY|O_LARGEFILE; @@ -785,7 +786,8 @@ nfsd_open(struct svc_rqst *rqstp, struct svc_fh *fhp, umode_t type, if (IS_ERR(*filp)) host_err = PTR_ERR(*filp); else - host_err = ima_file_check(*filp, access); + host_err = ima_file_check(*filp, may_flags); + out_nfserr: err = nfserrno(host_err); out: