History log of /openbmc/linux/fs/nfs/nfs4proc.c (Results 26 – 50 of 3697)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 5bab56ff 07-Feb-2023 NeilBrown <neilb@suse.de>

NFS: fix disabling of swap

When swap is activated to a file on an NFSv4 mount we arrange that the
state manager thread is always present as starting a new thread requires
memory allocations that mig

NFS: fix disabling of swap

When swap is activated to a file on an NFSv4 mount we arrange that the
state manager thread is always present as starting a new thread requires
memory allocations that might block waiting for swap.

Unfortunately the code for allowing the state manager thread to exit when
swap is disabled was not tested properly and does not work.
This can be seen by examining /proc/fs/nfsfs/servers after disabling swap
and unmounting the filesystem. The servers file will still list one
entry. Also a "ps" listing will show the state manager thread is still
present.

There are two problems.
1/ rpc_clnt_swap_deactivate() doesn't walk up the ->cl_parent list to
find the primary client on which the state manager runs.

2/ The thread is not woken up properly and it immediately goes back to
sleep without checking whether it is really needed. Using
nfs4_schedule_state_manager() ensures a proper wake-up.

Reported-by: Olga Kornievskaia <aglo@umich.edu>
Fixes: 4dc73c679114 ("NFSv4: keep state manager thread active if swap is enabled")
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>

show more ...


Revision tags: v6.1.9, v6.1.8, v6.1.7, v6.1.6
# 39f60c1c 13-Jan-2023 Christian Brauner <brauner@kernel.org>

fs: port xattr to mnt_idmap

Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conver

fs: port xattr to mnt_idmap

Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>

show more ...


Revision tags: v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1
# ef8d98f2 09-Oct-2022 NeilBrown <neilb@suse.de>

NFS: avoid spurious warning of lost lock that is being unlocked.

When the NFSv4 state manager recovers state after a server restart, it
reports that locks have been lost if it finds any lock state f

NFS: avoid spurious warning of lost lock that is being unlocked.

When the NFSv4 state manager recovers state after a server restart, it
reports that locks have been lost if it finds any lock state for which
recovery hasn't been successful. i.e. any for which
NFS_LOCK_INITIALIZED is not set.

However it only tries to recover locks that are still linked to
inode->i_flctx. So if a lock has been removed from inode->i_flctx, but
the state for that lock has not yet been destroyed, then a spurious
warning results.

nfs4_proc_unlck() calls locks_lock_inode_wait() - which removes the lock
from ->i_flctx - before sending the unlock request to the server and
before the final nfs4_put_lock_state() is called. This allows a window
in which a spurious warning can be produced.

So add a new flag NFS_LOCK_UNLOCKING which is set once the decision has
been made to unlock the lock. This will prevent it from triggering any
warning.

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


Revision tags: v5.15.72, v6.0, v5.15.71, v5.15.70
# d564d2c4 23-Sep-2022 ChenXiaoSong <chenxiaosong2@huawei.com>

NFSv4: check FMODE_EXEC from open context mode in nfs4_opendata_access()

After converting file f_flags to open context mode by flags_to_mode(), open
context mode will have FMODE_EXEC when file open

NFSv4: check FMODE_EXEC from open context mode in nfs4_opendata_access()

After converting file f_flags to open context mode by flags_to_mode(), open
context mode will have FMODE_EXEC when file open for exec, so we check
FMODE_EXEC from open context mode.

No functional change, just simplify the code.

Signed-off-by: ChenXiaoSong <chenxiaosong2@huawei.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


# 51069e4a 04-Nov-2022 Trond Myklebust <trond.myklebust@hammerspace.com>

NFSv4: Fix a deadlock between nfs4_open_recover_helper() and delegreturn

If we're asked to recover open state while a delegation return is
outstanding, then the state manager thread cannot use a cac

NFSv4: Fix a deadlock between nfs4_open_recover_helper() and delegreturn

If we're asked to recover open state while a delegation return is
outstanding, then the state manager thread cannot use a cached open, so
if the server returns a delegation, we can end up deadlocked behind the
pending delegreturn.
To avoid this problem, let's just ask the server not to give us a
delegation unless we're explicitly reclaiming one.

Fixes: be36e185bd26 ("NFSv4: nfs4_open_recover_helper() must set share access")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


# e83458fc 27-Oct-2022 Trond Myklebust <trond.myklebust@hammerspace.com>

NFSv4: Fix a credential leak in _nfs4_discover_trunking()

Fixes: 4f40a5b55446 ("NFSv4: Add an fattr allocation to _nfs4_discover_trunking()")
Signed-off-by: Trond Myklebust <trond.myklebust@hammersp

NFSv4: Fix a credential leak in _nfs4_discover_trunking()

Fixes: 4f40a5b55446 ("NFSv4: Add an fattr allocation to _nfs4_discover_trunking()")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


# c528f70f 19-Oct-2022 Trond Myklebust <trond.myklebust@hammerspace.com>

NFSv4.2: Fix initialisation of struct nfs4_label

The call to nfs4_label_init_security() should return a fully initialised
label.

Fixes: aa9c2669626c ("NFS: Client implementation of Labeled-NFS")
Si

NFSv4.2: Fix initialisation of struct nfs4_label

The call to nfs4_label_init_security() should return a fully initialised
label.

Fixes: aa9c2669626c ("NFS: Client implementation of Labeled-NFS")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


# f5ea1613 19-Oct-2022 Benjamin Coddington <bcodding@redhat.com>

NFSv4: Retry LOCK on OLD_STATEID during delegation return

There's a small window where a LOCK sent during a delegation return can
race with another OPEN on client, but the open stateid has not yet b

NFSv4: Retry LOCK on OLD_STATEID during delegation return

There's a small window where a LOCK sent during a delegation return can
race with another OPEN on client, but the open stateid has not yet been
updated. In this case, the client doesn't handle the OLD_STATEID error
from the server and will lose this lock, emitting:
"NFS: nfs4_handle_delegation_recall_error: unhandled error -10024".

Fix this by sending the task through the nfs4 error handling in
nfs4_lock_done() when we may have to reconcile our stateid with what the
server believes it to be. For this case, the result is a retry of the
LOCK operation with the updated stateid.

Reported-by: Gonzalo Siero Humet <gsierohu@redhat.com>
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>

show more ...


# cf0d7e7f 16-Oct-2022 Kees Cook <keescook@chromium.org>

NFS: Avoid memcpy() run-time warning for struct sockaddr overflows

The 'nfs_server' and 'mount_server' structures include a union of
'struct sockaddr' (with the older 16 bytes max address size) and

NFS: Avoid memcpy() run-time warning for struct sockaddr overflows

The 'nfs_server' and 'mount_server' structures include a union of
'struct sockaddr' (with the older 16 bytes max address size) and
'struct sockaddr_storage' which is large enough to hold all the
supported sa_family types (128 bytes max size). The runtime memcpy()
buffer overflow checker is seeing attempts to write beyond the 16
bytes as an overflow, but the actual expected size is that of 'struct
sockaddr_storage'. Plumb the use of 'struct sockaddr_storage' more
completely through-out NFS, which results in adjusting the memcpy()
buffers to the correct union members. Avoids this false positive run-time
warning under CONFIG_FORTIFY_SOURCE:

memcpy: detected field-spanning write (size 28) of single field "&ctx->nfs_server.address" at fs/nfs/namespace.c:178 (size 16)

Reported-by: kernel test robot <yujie.liu@intel.com>
Link: https://lore.kernel.org/all/202210110948.26b43120-yujie.liu@intel.com
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: Anna Schumaker <anna@kernel.org>
Cc: linux-nfs@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>

show more ...


Revision tags: v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48
# 7e7ce2cc 15-Jun-2022 yuzhe <yuzhe@nfschina.com>

nfs: remove unnecessary (void*) conversions.

remove unnecessary void* type castings.

Signed-off-by: yuzhe <yuzhe@nfschina.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>


# f5d39b02 22-Aug-2022 Peter Zijlstra <peterz@infradead.org>

freezer,sched: Rewrite core freezer logic

Rewrite the core freezer to behave better wrt thawing and be simpler
in general.

By replacing PF_FROZEN with TASK_FROZEN, a special block state, it is
ensu

freezer,sched: Rewrite core freezer logic

Rewrite the core freezer to behave better wrt thawing and be simpler
in general.

By replacing PF_FROZEN with TASK_FROZEN, a special block state, it is
ensured frozen tasks stay frozen until thawed and don't randomly wake
up early, as is currently possible.

As such, it does away with PF_FROZEN and PF_FREEZER_SKIP, freeing up
two PF_flags (yay!).

Specifically; the current scheme works a little like:

freezer_do_not_count();
schedule();
freezer_count();

And either the task is blocked, or it lands in try_to_freezer()
through freezer_count(). Now, when it is blocked, the freezer
considers it frozen and continues.

However, on thawing, once pm_freezing is cleared, freezer_count()
stops working, and any random/spurious wakeup will let a task run
before its time.

That is, thawing tries to thaw things in explicit order; kernel
threads and workqueues before doing bringing SMP back before userspace
etc.. However due to the above mentioned races it is entirely possible
for userspace tasks to thaw (by accident) before SMP is back.

This can be a fatal problem in asymmetric ISA architectures (eg ARMv9)
where the userspace task requires a special CPU to run.

As said; replace this with a special task state TASK_FROZEN and add
the following state transitions:

TASK_FREEZABLE -> TASK_FROZEN
__TASK_STOPPED -> TASK_FROZEN
__TASK_TRACED -> TASK_FROZEN

The new TASK_FREEZABLE can be set on any state part of TASK_NORMAL
(IOW. TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE) -- any such state
is already required to deal with spurious wakeups and the freezer
causes one such when thawing the task (since the original state is
lost).

The special __TASK_{STOPPED,TRACED} states *can* be restored since
their canonical state is in ->jobctl.

With this, frozen tasks need an explicit TASK_FROZEN wakeup and are
free of undue (early / spurious) wakeups.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20220822114649.055452969@infradead.org

show more ...


# 2135e5d5 02-Aug-2022 Trond Myklebust <trond.myklebust@hammerspace.com>

NFSv4/pnfs: Fix a use-after-free bug in open

If someone cancels the open RPC call, then we must not try to free
either the open slot or the layoutget operation arguments, since they
are likely still

NFSv4/pnfs: Fix a use-after-free bug in open

If someone cancels the open RPC call, then we must not try to free
either the open slot or the layoutget operation arguments, since they
are likely still in use by the hung RPC call.

Fixes: 6949493884fe ("NFSv4: Don't hold the layoutget locks across multiple RPC calls")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


# e35a5e78 27-Jul-2022 Zhang Xianwei <zhang.xianwei8@zte.com.cn>

NFSv4.1: RECLAIM_COMPLETE must handle EACCES

A client should be able to handle getting an EACCES error while doing
a mount operation to reclaim state due to NFS4CLNT_RECLAIM_REBOOT
being set. If the

NFSv4.1: RECLAIM_COMPLETE must handle EACCES

A client should be able to handle getting an EACCES error while doing
a mount operation to reclaim state due to NFS4CLNT_RECLAIM_REBOOT
being set. If the server returns RPC_AUTH_BADCRED because authentication
failed when we execute "exportfs -au", then RECLAIM_COMPLETE will go a
wrong way. After mount succeeds, all OPEN call will fail due to an
NFS4ERR_GRACE error being returned. This patch is to fix it by resending
a RPC request.

Signed-off-by: Zhang Xianwei <zhang.xianwei8@zte.com.cn>
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
Fixes: aa5190d0ed7d ("NFSv4: Kill nfs4_async_handle_error() abuses by NFSv4.1")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


# f201bdfd 25-Jul-2022 Olga Kornievskaia <olga.kornievskaia@gmail.com>

NFSv4.1 probe offline transports for trunking on session creation

Once the session is established call into the SUNRPC layer to check
if any offlined trunking connections should be re-enabled.

Sign

NFSv4.1 probe offline transports for trunking on session creation

Once the session is established call into the SUNRPC layer to check
if any offlined trunking connections should be re-enabled.

Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


# e818bd08 25-Jul-2022 Olga Kornievskaia <olga.kornievskaia@gmail.com>

NFSv4.1 remove xprt from xprt_switch if session trunking test fails

If we are doing a session trunking test and it fails for the transport,
then remove this transport from the xprt_switch group.

Si

NFSv4.1 remove xprt from xprt_switch if session trunking test fails

If we are doing a session trunking test and it fails for the transport,
then remove this transport from the xprt_switch group.

Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


# 88363d3e 25-Jul-2022 Olga Kornievskaia <olga.kornievskaia@gmail.com>

NFSv4.1 offline trunkable transports on DESTROY_SESSION

When session is destroy, some of the transports might no longer be
valid trunks for the new session. Offline existing transports.

Signed-off-

NFSv4.1 offline trunkable transports on DESTROY_SESSION

When session is destroy, some of the transports might no longer be
valid trunks for the new session. Offline existing transports.

Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


# 7ccafd4b 12-Jul-2022 Trond Myklebust <trond.myklebust@hammerspace.com>

NFSv4.1: Handle NFS4ERR_DELAY replies to OP_SEQUENCE correctly

Don't assume that the NFS4ERR_DELAY means that the server is processing
this slot id.

Fixes: 3453d5708b33 ("NFSv4.1: Avoid false retri

NFSv4.1: Handle NFS4ERR_DELAY replies to OP_SEQUENCE correctly

Don't assume that the NFS4ERR_DELAY means that the server is processing
this slot id.

Fixes: 3453d5708b33 ("NFSv4.1: Avoid false retries when RPC calls are interrupted")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


# f07a5d24 12-Jul-2022 Trond Myklebust <trond.myklebust@hammerspace.com>

NFSv4.1: Don't decrease the value of seq_nr_highest_sent

When we're trying to figure out what the server may or may not have seen
in terms of request numbers, do not assume that requests with a larg

NFSv4.1: Don't decrease the value of seq_nr_highest_sent

When we're trying to figure out what the server may or may not have seen
in terms of request numbers, do not assume that requests with a larger
number were missed, just because we saw a reply to a request with a
smaller number.

Fixes: 3453d5708b33 ("NFSv4.1: Avoid false retries when RPC calls are interrupted")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>

show more ...


# 4f40a5b5 27-Jun-2022 Scott Mayhew <smayhew@redhat.com>

NFSv4: Add an fattr allocation to _nfs4_discover_trunking()

This was missed in c3ed222745d9 ("NFSv4: Fix free of uninitialized
nfs4_label on referral lookup.") and causes a panic when mounting
with

NFSv4: Add an fattr allocation to _nfs4_discover_trunking()

This was missed in c3ed222745d9 ("NFSv4: Fix free of uninitialized
nfs4_label on referral lookup.") and causes a panic when mounting
with '-o trunkdiscovery':

PID: 1604 TASK: ffff93dac3520000 CPU: 3 COMMAND: "mount.nfs"
#0 [ffffb79140f738f8] machine_kexec at ffffffffaec64bee
#1 [ffffb79140f73950] __crash_kexec at ffffffffaeda67fd
#2 [ffffb79140f73a18] crash_kexec at ffffffffaeda76ed
#3 [ffffb79140f73a30] oops_end at ffffffffaec2658d
#4 [ffffb79140f73a50] general_protection at ffffffffaf60111e
[exception RIP: nfs_fattr_init+0x5]
RIP: ffffffffc0c18265 RSP: ffffb79140f73b08 RFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff93dac304a800 RCX: 0000000000000000
RDX: ffffb79140f73bb0 RSI: ffff93dadc8cbb40 RDI: d03ee11cfaf6bd50
RBP: ffffb79140f73be8 R8: ffffffffc0691560 R9: 0000000000000006
R10: ffff93db3ffd3df8 R11: 0000000000000000 R12: ffff93dac4040000
R13: ffff93dac2848e00 R14: ffffb79140f73b60 R15: ffffb79140f73b30
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#5 [ffffb79140f73b08] _nfs41_proc_get_locations at ffffffffc0c73d53 [nfsv4]
#6 [ffffb79140f73bf0] nfs4_proc_get_locations at ffffffffc0c83e90 [nfsv4]
#7 [ffffb79140f73c60] nfs4_discover_trunking at ffffffffc0c83fb7 [nfsv4]
#8 [ffffb79140f73cd8] nfs_probe_fsinfo at ffffffffc0c0f95f [nfs]
#9 [ffffb79140f73da0] nfs_probe_server at ffffffffc0c1026a [nfs]
RIP: 00007f6254fce26e RSP: 00007ffc69496ac8 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6254fce26e
RDX: 00005600220a82a0 RSI: 00005600220a64d0 RDI: 00005600220a6520
RBP: 00007ffc69496c50 R8: 00005600220a8710 R9: 003035322e323231
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffc69496c50
R13: 00005600220a8440 R14: 0000000000000010 R15: 0000560020650ef9
ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002b

Fixes: c3ed222745d9 ("NFSv4: Fix free of uninitialized nfs4_label on referral lookup.")
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>

show more ...


Revision tags: v5.15.47, v5.15.46, v5.15.45, v5.15.44
# 118f09ed 25-May-2022 Olga Kornievskaia <kolga@netapp.com>

NFSv4.1 mark qualified async operations as MOVEABLE tasks

Mark async operations such as RENAME, REMOVE, COMMIT MOVEABLE
for the nfsv4.1+ sessions.

Fixes: 85e39feead948 ("NFSv4.1 identify and mark R

NFSv4.1 mark qualified async operations as MOVEABLE tasks

Mark async operations such as RENAME, REMOVE, COMMIT MOVEABLE
for the nfsv4.1+ sessions.

Fixes: 85e39feead948 ("NFSv4.1 identify and mark RPC tasks that can move between transports")
Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>

show more ...


Revision tags: v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40
# c3ed2227 14-May-2022 Benjamin Coddington <bcodding@redhat.com>

NFSv4: Fix free of uninitialized nfs4_label on referral lookup.

Send along the already-allocated fattr along with nfs4_fs_locations, and
drop the memcpy of fattr. We end up growing two more allocat

NFSv4: Fix free of uninitialized nfs4_label on referral lookup.

Send along the already-allocated fattr along with nfs4_fs_locations, and
drop the memcpy of fattr. We end up growing two more allocations, but this
fixes up a crash as:

PID: 790 TASK: ffff88811b43c000 CPU: 0 COMMAND: "ls"
#0 [ffffc90000857920] panic at ffffffff81b9bfde
#1 [ffffc900008579c0] do_trap at ffffffff81023a9b
#2 [ffffc90000857a10] do_error_trap at ffffffff81023b78
#3 [ffffc90000857a58] exc_stack_segment at ffffffff81be1f45
#4 [ffffc90000857a80] asm_exc_stack_segment at ffffffff81c009de
#5 [ffffc90000857b08] nfs_lookup at ffffffffa0302322 [nfs]
#6 [ffffc90000857b70] __lookup_slow at ffffffff813a4a5f
#7 [ffffc90000857c60] walk_component at ffffffff813a86c4
#8 [ffffc90000857cb8] path_lookupat at ffffffff813a9553
#9 [ffffc90000857cf0] filename_lookup at ffffffff813ab86b

Suggested-by: Trond Myklebust <trondmy@hammerspace.com>
Fixes: 9558a007dbc3 ("NFS: Remove the label from the nfs4_lookup_res struct")
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>

show more ...


# 71342db0 14-May-2022 Trond Myklebust <trond.myklebust@hammerspace.com>

NFSv4.1: Enable access to the NFSv4.1 'dacl' and 'sacl' attributes

Enable access to the NFSv4 acl via the NFSv4.1 'dacl' and 'sacl'
attributes.
This allows the server to authenticate the DACL and th

NFSv4.1: Enable access to the NFSv4.1 'dacl' and 'sacl' attributes

Enable access to the NFSv4 acl via the NFSv4.1 'dacl' and 'sacl'
attributes.
This allows the server to authenticate the DACL and the SACL operations
separately, since reading and/or editing the SACL is usually considered
to be a privileged operation.
It also allows the propagation of automatic inheritance information that
was not supported by the NFSv4.0 'acl' attribute.

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>

show more ...


# db145db0 14-May-2022 Trond Myklebust <trond.myklebust@hammerspace.com>

NFSv4: Add encoders/decoders for the NFSv4.1 dacl and sacl attributes

Add the ability to set or retrieve the acl using the NFSv4.1 'dacl' and
'sacl' attributes to the NFSv4 xdr encoders/decoders.

S

NFSv4: Add encoders/decoders for the NFSv4.1 dacl and sacl attributes

Add the ability to set or retrieve the acl using the NFSv4.1 'dacl' and
'sacl' attributes to the NFSv4 xdr encoders/decoders.

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>

show more ...


# 7b8b44eb 14-May-2022 Trond Myklebust <trond.myklebust@hammerspace.com>

NFSv4: Specify the type of ACL to cache

When caching a NFSv4 ACL, we want to specify whether we are caching an
NFSv4.0 type acl, the NFSv4.1 dacl or the NFSv4.1 sacl.

Signed-off-by: Trond Myklebust

NFSv4: Specify the type of ACL to cache

When caching a NFSv4 ACL, we want to specify whether we are caching an
NFSv4.0 type acl, the NFSv4.1 dacl or the NFSv4.1 sacl.

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>

show more ...


# 69494938 14-May-2022 Trond Myklebust <trond.myklebust@hammerspace.com>

NFSv4: Don't hold the layoutget locks across multiple RPC calls

When doing layoutget as part of the open() compound, we have to be
careful to release the layout locks before we can call any further

NFSv4: Don't hold the layoutget locks across multiple RPC calls

When doing layoutget as part of the open() compound, we have to be
careful to release the layout locks before we can call any further RPC
calls, such as setattr(). The reason is that those calls could trigger
a recall, which could deadlock.

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>

show more ...


12345678910>>...148