Open causes oops instead of EPERM

From Linux NFS

Revision as of 16:12, 22 October 2010 by Amschuma (Talk | contribs)
Jump to: navigation, search



  • Kernel version: 2.6.34-rc1, 2.6.34-rc2
  • Bug 15674
  • Reported by: Daniel J Blueman (March 29, 2010)
  • Fixed by: Al Viro (April 8, 2010)


  • User attempts to open a file they do not have permissions for
  • We expect EPERM, instead we see an oops
  • On local filesystem:
$ touch /tmp/foo
$ sudo chmod 0 /tmp/foo
$ cat /tmp/foo
cat: /tmp/foo: Permission denied
  • On NFS filesystem:
$ touch /net/users/daniel/foo
$ sudo chmod 0 /net/users/daniel/foo
$ cat /net/users/daniel/foo

--- [2]

BUG: unable to handle kernel NULL pointer dereference at 000000000000000b


  • nfs4_open_revalidate() did not check the return value of lookup_instantiate_filp()


commit 04287f975e68038051eb9c79896866d36610b8e0
Author: Al Viro <>
Date:   Thu Apr 8 00:06:07 2010 +0100

    Have nfs ->d_revalidate() report errors properly
        If nfs atomic open implementation ends up doing open request from
    ->d_revalidate() codepath and gets an error from server, return that error
    to caller explicitly and don't bother with lookup_instantiate_filp() at all.
    ->d_revalidate() can return an error itself just fine...
    for original report.
    Reported-by: Daniel J Blueman <>
    Signed-off-by: Al Viro <>
    Signed-off-by: Linus Torvalds <>

Personal tools