#
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 ...
|