History log of /openbmc/linux/fs/nfsd/vfs.c (Results 226 – 250 of 413)
Revision Date Author Comments
# fac7a17b 27-Jul-2012 J. Bruce Fields <bfields@redhat.com>

nfsd4: cast readlink() bug argument

As we already do in readv, writev.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>


# 4a55c101 12-Jun-2012 Jan Kara <jack@suse.cz>

nfsd: Push mnt_want_write() outside of i_mutex

When mnt_want_write() starts to handle freezing it will get a full lock
semantics requiring proper lock ordering. So push mnt_want_write() call
consist

nfsd: Push mnt_want_write() outside of i_mutex

When mnt_want_write() starts to handle freezing it will get a full lock
semantics requiring proper lock ordering. So push mnt_want_write() call
consistently outside of i_mutex.

CC: linux-nfs@vger.kernel.org
CC: "J. Bruce Fields" <bfields@fieldses.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

show more ...


# 765927b2 26-Jun-2012 Al Viro <viro@zeniv.linux.org.uk>

switch dentry_open() to struct path, make it grab references itself

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>


# 312b63fb 10-Jun-2012 Al Viro <viro@zeniv.linux.org.uk>

don't pass nameidata * to vfs_create()

all we want is a boolean flag, same as the method gets now

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>


# d91d0b56 06-Jun-2012 J. Bruce Fields <bfields@redhat.com>

nfsd: allow owner_override only for regular files

We normally allow the owner of a file to override permissions checks on
IO operations, since:
- the client will take responsibility for doing an ac

nfsd: allow owner_override only for regular files

We normally allow the owner of a file to override permissions checks on
IO operations, since:
- the client will take responsibility for doing an access check
on open;
- the permission checks offer no protection against malicious
clients--if they can authenticate as the file's owner then
they can always just change its permissions;
- checking permission on each IO operation breaks the usual
posix rule that permission is checked only on open.

However, we've never allowed the owner to override permissions on
readdir operations, even though the above logic would also apply to
directories. I've never heard of this causing a problem, probably
because a) simultaneously opening and creating a directory (with
restricted mode) isn't possible, and b) opening a directory, then
chmod'ing it, is rare.

Our disallowal of owner-override on directories appears to be an
accident, though--the readdir itself succeeds, and then we fail just
because lookup_one_len() calls in our filldir methods fail.

I'm not sure what the easiest fix for that would be. For now, just make
this behavior obvious by denying the override right at the start.

This also fixes some odd v4 behavior: with the rdattr_error attribute
requested, it would perform the readdir but return an ACCES error with
each entry.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# b108fe6b 25-Apr-2012 Jeff Layton <jlayton@redhat.com>

nfsd: trivial: use SEEK_SET instead of 0 in vfs_llseek

They're equivalent, but SEEK_SET is more informative...

Cc: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>

nfsd: trivial: use SEEK_SET instead of 0 in vfs_llseek

They're equivalent, but SEEK_SET is more informative...

Cc: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# 9dc4e6c4 09-Apr-2012 J. Bruce Fields <bfields@redhat.com>

nfsd: don't fail unchecked creates of non-special files

Allow a v3 unchecked open of a non-regular file succeed as if it were a
lookup; typically a client in such a case will want to fall back on a

nfsd: don't fail unchecked creates of non-special files

Allow a v3 unchecked open of a non-regular file succeed as if it were a
lookup; typically a client in such a case will want to fall back on a
local open, so succeeding and giving it the filehandle is more useful
than failing with nfserr_exist, which makes it appear that nothing at
all exists by that name.

Similarly for v4, on an open-create, return the same errors we would on
an attempt to open a non-regular file, instead of returning
nfserr_exist.

This fixes a problem found doing a v4 open of a symlink with
O_RDONLY|O_CREAT, which resulted in the current client returning EEXIST.

Thanks also to Trond for analysis.

Cc: stable@kernel.org
Reported-by: Orion Poplawski <orion@cora.nwra.com>
Tested-by: Orion Poplawski <orion@cora.nwra.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# 68ac1234 15-Mar-2012 Al Viro <viro@zeniv.linux.org.uk>

switch touch_atime to struct path

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>


# 06effdbb 18-Mar-2012 Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>

nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes)

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 ra

nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes)

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>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Acked-by: J. Bruce Fields<bfields@redhat.com>

show more ...


# 999448a8 18-Mar-2012 Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>

nfsd: rename 'int access' to 'int may_flags' in nfsd_open()

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:

nfsd: rename 'int access' to 'int may_flags' in nfsd_open()

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>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Acked-by: J. Bruce Fields<bfields@redhat.com>

show more ...


# 9b4146e8 04-Jan-2012 Chuck Lever <chuck.lever@oracle.com>

NFSD: Change name of extended attribute containing junction

As of fedfs-utils-0.8.0, user space stores all NFS junction
information in a single extended attribute: "trusted.junction.nfs".

Both FedF

NFSD: Change name of extended attribute containing junction

As of fedfs-utils-0.8.0, user space stores all NFS junction
information in a single extended attribute: "trusted.junction.nfs".

Both FedFS and NFS basic junctions are stored in this one attribute,
and the intention is that all future forms of NFS junction metadata
will be stored in this attribute. Other protocols may use a different
extended attribute.

Thus NFSD needs to look only for that one extended attribute. The
"trusted.junction.type" xattr is deprecated. fedfs-utils-0.8.0 will
continue to attach a "trusted.junction.type" xattr to junctions, but
future fedfs-utils releases may no longer do that.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# 175a4eb7 26-Jul-2011 Al Viro <viro@zeniv.linux.org.uk>

fs: propagate umode_t, misc bits

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>


# bad0dcff 23-Nov-2011 Al Viro <viro@zeniv.linux.org.uk>

new helpers: fh_{want,drop}_write()

A bunch of places in nfsd does mnt_{want,drop}_write on vfsmount of
export of given fhandle. Switched to obvious inlined helpers...

Signed-off-by: Al Viro <viro

new helpers: fh_{want,drop}_write()

A bunch of places in nfsd does mnt_{want,drop}_write on vfsmount of
export of given fhandle. Switched to obvious inlined helpers...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

show more ...


# 856121b2 13-Oct-2011 J. Bruce Fields <bfields@redhat.com>

nfsd4: warn on open failure after create

If we create the object and then return failure to the client, we're
left with an unexpected file in the filesystem.

I'm trying to eliminate such cases but

nfsd4: warn on open failure after create

If we create the object and then return failure to the client, we're
left with an unexpected file in the filesystem.

I'm trying to eliminate such cases but not 100% sure I have so an
assertion might be helpful for now.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# 11fcee02 12-Sep-2011 Trond Myklebust <Trond.Myklebust@netapp.com>

NFSD: Add a cache for fs_locations information

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
[ cel: since this is server-side, use nfsd4_ prefix instead of nfs4_ prefix. ]
[ cel: imple

NFSD: Add a cache for fs_locations information

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
[ cel: since this is server-side, use nfsd4_ prefix instead of nfs4_ prefix. ]
[ cel: implement S_ISVTX filter in bfields-normal form ]
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# a043226b 25-Aug-2011 J. Bruce Fields <bfields@redhat.com>

nfsd4: permit read opens of executable-only files

A client that wants to execute a file must be able to read it. Read
opens over nfs are therefore implicitly allowed for executable files
even when

nfsd4: permit read opens of executable-only files

A client that wants to execute a file must be able to read it. Read
opens over nfs are therefore implicitly allowed for executable files
even when those files are not readable.

NFSv2/v3 get this right by using a passed-in NFSD_MAY_OWNER_OVERRIDE on
read requests, but NFSv4 has gotten this wrong ever since
dc730e173785e29b297aa605786c94adaffe2544 "nfsd4: fix owner-override on
open", when we realized that the file owner shouldn't override
permissions on non-reclaim NFSv4 opens.

So we can't use NFSD_MAY_OWNER_OVERRIDE to tell nfsd_permission to allow
reads of executable files.

So, do the same thing we do whenever we encounter another weird NFS
permission nit: define yet another NFSD_MAY_* flag.

The industry's future standardization on 128-bit processors will be
motivated primarily by the need for integers with enough bits for all
the NFSD_MAY_* flags.

Reported-by: Leonardo Borda <leonardoborda@gmail.com>
Cc: stable@kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# e281d810 15-Aug-2011 J. Bruce Fields <bfields@redhat.com>

nfsd4: fix incorrect comment in nfsd4_set_nfs4_acl

Zero means "I don't care what kind of file this is". And that's
probably what we want--acls are also settable at least on directories,
and if the

nfsd4: fix incorrect comment in nfsd4_set_nfs4_acl

Zero means "I don't care what kind of file this is". And that's
probably what we want--acls are also settable at least on directories,
and if the filesystem doesn't want them on other objects, leave it to it
to complain.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# 7d818a7b 15-Aug-2011 J. Bruce Fields <bfields@redhat.com>

nfsd: open-code special directory-hardlink check

We allow the fh_verify caller to specify that any object *except* those
of a given type is allowed, by passing a negative type. But only one
caller

nfsd: open-code special directory-hardlink check

We allow the fh_verify caller to specify that any object *except* those
of a given type is allowed, by passing a negative type. But only one
caller actually uses it. Open-code that check in the one caller.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# 105f4622 07-Jun-2011 J. Bruce Fields <bfields@redhat.com>

nfsd4: fix break_lease flags on nfsd open

Thanks to Casey Bodley for pointing out that on a read open we pass 0,
instead of O_RDONLY, to break_lease, with the result that a read open is
treated like

nfsd4: fix break_lease flags on nfsd open

Thanks to Casey Bodley for pointing out that on a read open we pass 0,
instead of O_RDONLY, to break_lease, with the result that a read open is
treated like a write open for the purposes of lease breaking!

Reported-by: Casey Bodley <cbodley@citi.umich.edu>
Cc: stable@kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# 7d751f6f 03-Jun-2011 Casey Bodley <cbodley@citi.umich.edu>

nfsd: link returns nfserr_delay when breaking lease

fix for commit 4795bb37effb7b8fe77e2d2034545d062d3788a8, nfsd: break
lease on unlink, link, and rename

if the LINK operation breaks a delegation,

nfsd: link returns nfserr_delay when breaking lease

fix for commit 4795bb37effb7b8fe77e2d2034545d062d3788a8, nfsd: break
lease on unlink, link, and rename

if the LINK operation breaks a delegation, it returns NFS4ERR_NOENT
(which is not a valid error in rfc 5661) instead of NFS4ERR_DELAY.
the return value of nfsd_break_lease() in nfsd_link() must be
converted from host_err to err

Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
Cc: stable@kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# fccb13c9 27-Apr-2011 Bryan Schumaker <bjschuma@netapp.com>

NFSD: Remove setting unused variable in nfsd_vfs_read()

Compiling gave me this warning:
fs/nfsd/vfs.c: In function ‘nfsd_vfs_read’:
fs/nfsd/vfs.c:880:16: warning: variable ‘inode’ set but not used
[

NFSD: Remove setting unused variable in nfsd_vfs_read()

Compiling gave me this warning:
fs/nfsd/vfs.c: In function ‘nfsd_vfs_read’:
fs/nfsd/vfs.c:880:16: warning: variable ‘inode’ set but not used
[-Wunused-but-set-variable]

I discovered that a local variable "inode" was being set towards the
beginning of nfsd_vfs_read() and then ignored for the rest of the
function.

Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# ac6721a1 20-Apr-2011 Mi Jinlong <mijinlong@cn.fujitsu.com>

nfsd41: make sure nfs server process OPEN with EXCLUSIVE4_1 correctly

The NFS server uses nfsd_create_v3 to handle EXCLUSIVE4_1 opens, but
that function is not prepared to handle them.

Rename nfsd_

nfsd41: make sure nfs server process OPEN with EXCLUSIVE4_1 correctly

The NFS server uses nfsd_create_v3 to handle EXCLUSIVE4_1 opens, but
that function is not prepared to handle them.

Rename nfsd_create_v3() to do_nfsd_create(), and add handling of
EXCLUSIVE4_1.

Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# 1574dff8 20-Apr-2011 Sachin Prabhu <sprabhu@redhat.com>

Open with O_CREAT flag set fails to open existing files on non writable directories

An open on a NFS4 share using the O_CREAT flag on an existing file for
which we have permissions to open but conta

Open with O_CREAT flag set fails to open existing files on non writable directories

An open on a NFS4 share using the O_CREAT flag on an existing file for
which we have permissions to open but contained in a directory with no
write permissions will fail with EACCES.

A tcpdump shows that the client had set the open mode to UNCHECKED which
indicates that the file should be created if it doesn't exist and
encountering an existing flag is not an error. Since in this case the
file exists and can be opened by the user, the NFS server is wrong in
attempting to check create permissions on the parent directory.

The patch adds a conditional statement to check for create permissions
only if the file doesn't exist.

Signed-off-by: Sachin S. Prabhu <sprabhu@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


# 29a78a3e 09-Apr-2011 J. Bruce Fields <bfields@redhat.com>

nfsd4: make fh_verify responsibility of nfsd_lookup_dentry caller

The secinfo caller actually won't want this.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>


# aea93397 10-Apr-2011 J. Bruce Fields <bfields@redhat.com>

nfsd: distinguish functions of NFSD_MAY_* flags

Most of the NFSD_MAY_* flags actually request permissions, but over the
years we've accreted a few that modify the behavior of the permission or
open

nfsd: distinguish functions of NFSD_MAY_* flags

Most of the NFSD_MAY_* flags actually request permissions, but over the
years we've accreted a few that modify the behavior of the permission or
open code in other ways.

Distinguish the two cases a little more. In particular, allow the
shortcut at the start of nfsd_permission to ignore the
non-permission-requesting bits.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>

show more ...


12345678910>>...17