aboutsummaryrefslogtreecommitdiffstats
path: root/fs/nfs
AgeCommit message (Collapse)Author
2024-04-09Merge tag 'v6.1.84' into v6.1/standard/baseBruce Ashfield
This is the 6.1.84 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmYNV6cACgkQONu9yGCS # aT4HvBAAmblOq7LuUZQ7GdoPH6huJC4Znm0zLYcWZEhIFssA0Xm8lt57VEDrsJft # DYpNCNWOo42v2Ml15fTVEzeWHjcNWbewIBESJYaOSuRHt+6hihteoMu1ad2lM+aR # +CXE3PJjAipunnKtbdyS0z+g4WHuIVG/EgjvRdTzonznGODOiTz6D2KiRcIJo9kR # T+HwkPw/S+1N8yICGuMfJQzj9lF+NJpvFBxwFsm62RPXGD/xI2Q93upPoXdBlxXX # aWoR3HmkZ1EVXqkEIzFVviRn2QI22uKUGE942R38Wg5xdZcTrOeI5to0fX7rr+oA # sJVLQzmrnwaJWiBMXtiGbtwn1PdtIaZbMMrxJa471/plVv3aQW+fTNLOPW9wzPDV # 8Aap29bgvI0lDhbP5yK2uCCbpvN570cKWgk/xFmIGq7USfZNUOKXrg2uuHAC6BLo # U8PycpD2OvL/t0Y8gA/twjPsqqpoNPZuywUEWbfaWPvpnKPh0UweKXi1syqv41Th # //HQDrSzJxQuraWCoYvmG1R1jlOSOp7tiHNmnBCmbjJw1wEC9XOMwQ2frrVrRj1n # g4IDY04jcOQmbrgVqBkIRa1ZFFFpepZlDwnyYpmFpo8szPr+1YvJ8h/w/olcH11Q # 2VDenFG4E3nY/fjWclp4PmkVlmpXYMlciV89pDhOn/FVl8Adhp0= # =maia # -----END PGP SIGNATURE----- # gpg: Signature made Wed 03 Apr 2024 09:20:39 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-04-03nfs: fix UAF in direct writesJosef Bacik
[ Upstream commit 17f46b803d4f23c66cacce81db35fef3adb8f2af ] In production we have been hitting the following warning consistently ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30 This is because we're completing the nfs_direct_request twice in a row. The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq); However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfs_direct_request twice. The only other place we use nfs_generic_commit_list() is in __nfs_commit_inode, which wraps this call in a nfs_commit_begin(); nfs_commit_end(); Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with get_dreq()/put_dreq() calls around where we process events as well as in the completion paths. Fix this by using the same pattern for the commit requests. Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping. Signed-off-by: Josef Bacik <josef@toxicpanda.com> Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-28Merge tag 'v6.1.83' into v6.1/standard/baseBruce Ashfield
Linux 6.1.83 # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAmYDTlsACgkQ3qZv95d3 # LNx2Pw/8DMFid77ao/8dNIIsldgMFxz+7GQwQCHGWcJOm0QJVX5h51n7pH9i8t7Y # gBbnitOnEq9Oo5mDHaowNQnmcR1oB7BWpM+wcEN2L1eGqJFVOj1f5MdloUY9OLcO # l9Mq6lM+uojxc02i3y/J6WwLUZNs+3iVLnv30CyU4pjnbBB8OBm2JFyF3p+nl9oa # QL/6cqeOBKwyRu+cvNWsRchrN+uGBk+2l6ufwPup2o+U4gLKhdVSjpmO4km+DjM2 # KnZ8Qy4enDYT9whrMJ8mACb13+qHLm/HiVZycqr253SsbeJ9H1LX02RvAKqzrmqQ # KwOTM/p1Fep7NdqeANSyTSj+mU5ZP/ScApqXiLzEDOgpW5IfgBmCdIhvlqeJwm3s # kVhLM7Cs6UZmJuMibCztnv12xFUZyd8W9gBVD7M1wy/ANScJzF7c9+OC7iqPZqRt # tGq4ngMYDEPy/eIKJUaa2b5m1K6jeCzCxjig5GyLjJpKBJWK6HJGJ9eQLixLpotr # uOqlzIEHtGBerm69CNQFLUUqvqc4fGqZKHEBeIYUKrhOR3+ILTEHb/eiKaaBjJaD # inor8t6OyXZsm+SuoRsQY5czmzrJJYa3towh5Ha8dNUS6HzCemLykQWX+AALpVZ8 # UKh1swqxX2xNk4CGA3tS/Ti096GCZUoXIVlf3dZ5ejGrw+ocT+4= # =2pYy # -----END PGP SIGNATURE----- # gpg: Signature made Tue 26 Mar 2024 06:38:19 PM EDT # gpg: using RSA key E27E5D8A3403A2EF66873BBCDEA66FF797772CDC # gpg: Can't check signature: No public key
2024-03-26nfs: fix panic when nfs4_ff_layout_prepare_ds() failsJosef Bacik
[ Upstream commit 719fcafe07c12646691bd62d7f8d94d657fa0766 ] We've been seeing the following panic in production BUG: kernel NULL pointer dereference, address: 0000000000000065 PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0 RIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles] Call Trace: <TASK> ? __die+0x78/0xc0 ? page_fault_oops+0x286/0x380 ? __rpc_execute+0x2c3/0x470 [sunrpc] ? rpc_new_task+0x42/0x1c0 [sunrpc] ? exc_page_fault+0x5d/0x110 ? asm_exc_page_fault+0x22/0x30 ? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles] ? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles] ? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles] pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4] pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4] ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles] nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles] ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles] __nfs_pageio_add_request+0x154/0x6c0 [nfs] nfs_pageio_add_request+0x26b/0x380 [nfs] nfs_do_writepage+0x111/0x1e0 [nfs] nfs_writepages_callback+0xf/0x30 [nfs] write_cache_pages+0x17f/0x380 ? nfs_pageio_init_write+0x50/0x50 [nfs] ? nfs_writepages+0x6d/0x210 [nfs] ? nfs_writepages+0x6d/0x210 [nfs] nfs_writepages+0x125/0x210 [nfs] do_writepages+0x67/0x220 ? generic_perform_write+0x14b/0x210 filemap_fdatawrite_wbc+0x5b/0x80 file_write_and_wait_range+0x6d/0xc0 nfs_file_fsync+0x81/0x170 [nfs] ? nfs_file_mmap+0x60/0x60 [nfs] __x64_sys_fsync+0x53/0x90 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Inspecting the core with drgn I was able to pull this >>> prog.crashed_thread().stack_trace()[0] #0 at 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) in ff_layout_cancel_io at fs/nfs/flexfilelayout/flexfilelayout.c:2021:27 >>> prog.crashed_thread().stack_trace()[0]['idx'] (u32)1 >>> prog.crashed_thread().stack_trace()[0]['flseg'].mirror_array[1].mirror_ds (struct nfs4_ff_layout_ds *)0xffffffffffffffed This is clear from the stack trace, we call nfs4_ff_layout_prepare_ds() which could error out initializing the mirror_ds, and then we go to clean it all up and our check is only for if (!mirror->mirror_ds). This is inconsistent with the rest of the users of mirror_ds, which have if (IS_ERR_OR_NULL(mirror_ds)) to keep from tripping over this exact scenario. Fix this up in ff_layout_cancel_io() to make sure we don't panic when we get an error. I also spot checked all the other instances of checking mirror_ds and we appear to be doing the correct checks everywhere, only unconditionally dereferencing mirror_ds when we know it would be valid. Signed-off-by: Josef Bacik <josef@toxicpanda.com> Fixes: b739a5bd9d9f ("NFSv4/flexfiles: Cancel I/O if the layout is recalled or revoked") Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26NFS: Fix an off by one in root_nfs_cat()Christophe JAILLET
[ Upstream commit 698ad1a538da0b6bf969cfee630b4e3a026afb87 ] The intent is to check if 'dest' is truncated or not. So, >= should be used instead of >, because strlcat() returns the length of 'dest' and 'src' excluding the trailing NULL. Fixes: 56463e50d1fc ("NFS: Use super.c for NFSROOT mount option parsing") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26NFSv4.2: fix listxattr maximum XDR buffer sizeJorge Mora
[ Upstream commit bcac8bff90a6ee1629f90669cdb9d28fb86049b0 ] Switch order of operations to avoid creating a short XDR buffer: e.g., buflen = 12, old xdrlen = 12, new xdrlen = 20. Having a short XDR buffer leads to lxa_maxcount be a few bytes less than what is needed to retrieve the whole list when using a buflen as returned by a call with size = 0: buflen = listxattr(path, NULL, 0); buf = malloc(buflen); buflen = listxattr(path, buf, buflen); For a file with one attribute (name = '123456'), the first call with size = 0 will return buflen = 12 ('user.123456\x00'). The second call with size = 12, sends LISTXATTRS with lxa_maxcount = 12 + 8 (cookie) + 4 (array count) = 24. The XDR buffer needs 8 (cookie) + 4 (array count) + 4 (name count) + 6 (name len) + 2 (padding) + 4 (eof) = 28 which is 4 bytes shorter than the lxa_maxcount provided in the call. Fixes: 04a5da690e8f ("NFSv4.2: define limits and sizes for user xattr handling") Signed-off-by: Jorge Mora <mora@netapp.com> Reviewed-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102Jorge Mora
[ Upstream commit 251a658bbfceafb4d58c76b77682c8bf7bcfad65 ] A call to listxattr() with a buffer size = 0 returns the actual size of the buffer needed for a subsequent call. When size > 0, nfs4_listxattr() does not return an error because either generic_listxattr() or nfs4_listxattr_nfs4_label() consumes exactly all the bytes then size is 0 when calling nfs4_listxattr_nfs4_user() which then triggers the following kernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000) Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl', thus calling lisxattr() with size = 16 will trigger the bug. Add check on nfs4_listxattr() to return ERANGE error when it is called with size > 0 and the return value is greater than size. Fixes: 012a211abd5d ("NFSv4.2: hook in the user extended attribute handlers") Signed-off-by: Jorge Mora <mora@netapp.com> Reviewed-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26nfsd: allow reaping files still under writebackJeff Layton
[ Upstream commit dcb779fcd4ed5984ad15991d574943d12a8693d1 ] On most filesystems, there is no reason to delay reaping an nfsd_file just because its underlying inode is still under writeback. nfsd just relies on client activity or the local flusher threads to do writeback. The main exception is NFS, which flushes all of its dirty data on last close. Add a new EXPORT_OP_FLUSH_ON_CLOSE flag to allow filesystems to signal that they do this, and only skip closing files under writeback on such filesystems. Also, remove a redundant NULL file pointer check in nfsd_file_check_writeback, and clean up nfs's export op flag definitions. Signed-off-by: Jeff Layton <jlayton@kernel.org> Acked-by: Anna Schumaker <Anna.Schumaker@Netapp.com> [ cel: adjusted to apply to v6.1.y ] Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-10Merge tag 'v6.1.81' into v6.1/standard/baseBruce Ashfield
This is the 6.1.81 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmXogYcACgkQONu9yGCS # aT4cyA//ZR+UzUyvnZcZ2o7NKuuYw6GOD3RvtNEaFSRAksQVX4nmeg48ScwT6VaG # NdvJSfXOasDx75hiSXTShbtwP3hAh68fnKVzx8e2pzLDPyoIqrTAq3eR1DDg1y0+ # jh8CfddqY5wSsZQVmQUCNOr03m3U/K4QDp6bYTCESHzCkBcAsPPOf8JhJgkwkjnV # wzCGJ7DoOKcaSHnnyMIPYkW9gFdYvQeA8pIKnVGv5NcwmwI47VhQpdlPyC5t5SVj # cEr+bH/mioLdzd5tjdNSSRZ5EsP2VScSDfUQDK0HZMFzJDBe0w6vdg0v+SwzpYey # yMYHrPvRDvWIQ+STZbFZkzGpDv9v6nL1fpxgNyVc74SsaxQINC+XTtgnmglw2TYP # VZOGhdd1TZ2D83l20LO5U6NyiTH5QGzbTHK4nL4XYdycc4xRflP00zuveAhJmXCq # 2zhEybu0BWzWu02uLnNTi9INUTYEUo87ArXsTcy3RNT+TcEr6Hgj320Es6QSpuf6 # aM/5LN4c+o1iHrCuPwFZuO0YUmi75hrTsOGYYSQ1Fim7DXHB540lHucL+e0j5hHd # lL6JZCdGXJZ0hY8JAl1vlyjU9tJk+/L9yaQg1/AvaPxzycKe7b35I66IVTuz1W1b # QGpb1iVJEwvh7ZS7H+yg+FuIhIfBG+1E28D5aK0BOahwvzQGZWQ= # =puHB # -----END PGP SIGNATURE----- # gpg: Signature made Wed 06 Mar 2024 09:45:27 AM EST # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-03-06trace: Relocate event helper filesChuck Lever
[ Upstream commit 247c01ff5f8d66e62a404c91733be52fecb8b7f6 ] Steven Rostedt says: > The include/trace/events/ directory should only hold files that > are to create events, not headers that hold helper functions. > > Can you please move them out of include/trace/events/ as that > directory is "special" in the creation of events. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Acked-by: Leon Romanovsky <leonro@nvidia.com> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Stable-dep-of: 638593be55c0 ("NFSD: add CB_RECALL_ANY tracepoints") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-06NFS: Fix data corruption caused by congestion.NeilBrown
when AOP_WRITEPAGE_ACTIVATE is returned (as NFS does when it detects congestion) it is important that the page is redirtied. nfs_writepage_locked() doesn't do this, so files can become corrupted as writes can be lost. Note that this is not needed in v6.8 as AOP_WRITEPAGE_ACTIVATE cannot be returned. It is needed for kernels v5.18..v6.7. From 6.3 onward the patch is different as it needs to mention "folio", not "page". Reported-and-tested-by: Jacek Tomaka <Jacek.Tomaka@poczta.fm> Fixes: 6df25e58532b ("nfs: remove reliance on bdi congestion") Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-06Merge tag 'v6.1.75' into v6.1/standard/baseBruce Ashfield
This is the 6.1.75 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmWy7o0ACgkQONu9yGCS # aT76JA/9Gh3VNSLG35LaLyq3xGd827N6DPsMzeFHi+MGSyPVg0auE77QkHD/gZl9 # KynmBmz2+9DSoFxymWAS9oEPM8d/vw87AMuSTTct3GKkjEeUcj9lbeOEzgZydXX8 # cJSXvcCeKE3FESU/YbQKxo0N+r7tUDmnCR0edss5/FpYni3jPdg7jdESzGhiCHXj # r5rjrTE6h7Z/d+2kaKqlheL4o4OkV0YwnFnU2gC3MOOvLmgvXdOVQQsyaZ+WgSAN # 0JS0Q6Xk1xyYWx8iFaLGWIs1pUsQPKxIiRG3N/1KmXITopf2Pu68Yy7ST+YryDkO # nLcNrr3gsQxrM6MYnEhLzlxs3H1KuAVxJ4Y/dNqJnDxn0OJjcY3repwempz5Sxtk # 0OLDOsCICAiMHeF8rYIGhm09WdowLz0EH+sqadIGqWKzW/BcXqD+r9mpF1lwk1ZL # FJLgLmtOaG4amI46lEUHQ6ujN7Oad3gLYzudq2zKLeqonSIjm1TuDoMRvHWFsspO # 5i9I0x7Vlo3PqCl7kkKVL9PvVHx6BXJGFShABJqa9ao/oHxkOWuIt26pxUoLUN3P # 7Wa5WnfdlDd9nR3VGHcVe2ncuRmEfuriYpXvItJ7/KJKyIPkGoPehAh+vbZMoEy0 # DwhtD9PPsTlnUufbcZdHavYA1E4y/uXDMOIGB+ERpsTdXh9DwEo= # =2XHn # -----END PGP SIGNATURE----- # gpg: Signature made Thu 25 Jan 2024 06:28:13 PM EST # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-01-25pNFS: Fix the pnfs block driver's calculation of layoutget sizeTrond Myklebust
[ Upstream commit 8a6291bf3b0eae1bf26621e6419a91682f2d6227 ] Instead of relying on the value of the 'bytes_left' field, we should calculate the layout size based on the offset of the request that is being written out. Reported-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Fixes: 954998b60caa ("NFS: Fix error handling for O_DIRECT write scheduling") Reviewed-by: Benjamin Coddington <bcodding@redhat.com> Tested-by: Benjamin Coddington <bcodding@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-25NFSv4.1/pnfs: Ensure we handle the error NFS4ERR_RETURNCONFLICTTrond Myklebust
[ Upstream commit 037e56a22ff37f9a9c2330b66cff55d3d1ff9b90 ] Once the client has processed the CB_LAYOUTRECALL, but has not yet successfully returned the layout, the server is supposed to switch to returning NFS4ERR_RETURNCONFLICT. This patch ensures that we handle that return value correctly. Fixes: 183d9e7b112a ("pnfs: rework LAYOUTGET retry handling") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-25blocklayoutdriver: Fix reference leak of pnfs_device_nodeBenjamin Coddington
[ Upstream commit 1530827b90025cdf80c9b0d07a166d045a0a7b81 ] The error path for blocklayout's device lookup is missing a reference drop for the case where a lookup finds the device, but the device is marked with NFS_DEVICEID_UNAVAILABLE. Fixes: b3dce6a2f060 ("pnfs/blocklayout: handle transient devices") Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-11Merge tag 'v6.1.72' into v6.1/standard/baseBruce Ashfield
This is the 6.1.72 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmWewZgACgkQONu9yGCS # aT4QbA//eXPEBriitc4sKqjQPOO1z23NQztj0Y6mqOPAEZuqynIY84DWJESOVPhc # tPqilMP60U7dlOEOo0GDB14wLjh6i0TELg+UCxt9IIU1Glu3qOMMbfwkLgX65W2G # 5yrTeenp4s5LPsJv3h670FurNRSO1/29Q6byj4oEqEpHRvMixSZzlpmuk/8BN39q # XPJkyVgVygPjb4QQZjUYJSBj4I9/Ca1kqoSr9XfqbWf0iUG4HoJ+AyLuIF6uOuMQ # r9iiW8dTNXj/o/fwnC/SSf1BTRCwdeTBVlsVwYOjz7bFcCbuZD/1MR3xsNiZHo5y # VrW/0vVn0BWsR0z3gyFsQPxitamLrV1PlVfEVfrS0lmbcC/0wm5/t9lKn5/1ryPp # 1mskZGP4R3bXAz3q2YQ4wRRSqc/0pY182KNBwJ6G0bgysnkQDQQmMIX6JfDuXm77 # vjEsuzDCzyov9NJdDJCp0ZNMcCzAJheQFItIUOtv8J2S6ILwAIKq+s/Z/JZ7tT5F # rf0u7GMxWUtfTHmx8rVUvxOgdUvnJAR+wtT0l7kMd0sxWVS5MHsZ+143Sjdov2AM # idnuTrtnHfXshctoFTOuwY5fIAOd946IohQPaYEuIWGVFuBotzm8+O10eRK/qy+J # 0ob0owa+x+LtQYI6y67clmcWL/LRmDnncn4MtBedco+7rp4vmxA= # =lFgh # -----END PGP SIGNATURE----- # gpg: Signature made Wed 10 Jan 2024 11:11:04 AM EST # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2024-01-10mm, netfs, fscache: stop read optimisation when folio removed from pagecacheDavid Howells
[ Upstream commit b4fa966f03b7401ceacd4ffd7227197afb2b8376 ] Fscache has an optimisation by which reads from the cache are skipped until we know that (a) there's data there to be read and (b) that data isn't entirely covered by pages resident in the netfs pagecache. This is done with two flags manipulated by fscache_note_page_release(): if (... test_bit(FSCACHE_COOKIE_HAVE_DATA, &cookie->flags) && test_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags)) clear_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags); where the NO_DATA_TO_READ flag causes cachefiles_prepare_read() to indicate that netfslib should download from the server or clear the page instead. The fscache_note_page_release() function is intended to be called from ->releasepage() - but that only gets called if PG_private or PG_private_2 is set - and currently the former is at the discretion of the network filesystem and the latter is only set whilst a page is being written to the cache, so sometimes we miss clearing the optimisation. Fix this by following Willy's suggestion[1] and adding an address_space flag, AS_RELEASE_ALWAYS, that causes filemap_release_folio() to always call ->release_folio() if it's set, even if PG_private or PG_private_2 aren't set. Note that this would require folio_test_private() and page_has_private() to become more complicated. To avoid that, in the places[*] where these are used to conditionalise calls to filemap_release_folio() and try_to_release_page(), the tests are removed the those functions just jumped to unconditionally and the test is performed there. [*] There are some exceptions in vmscan.c where the check guards more than just a call to the releaser. I've added a function, folio_needs_release() to wrap all the checks for that. AS_RELEASE_ALWAYS should be set if a non-NULL cookie is obtained from fscache and cleared in ->evict_inode() before truncate_inode_pages_final() is called. Additionally, the FSCACHE_COOKIE_NO_DATA_TO_READ flag needs to be cleared and the optimisation cancelled if a cachefiles object already contains data when we open it. [dwysocha@redhat.com: call folio_mapping() inside folio_needs_release()] Link: https://github.com/DaveWysochanskiRH/kernel/commit/902c990e311120179fa5de99d68364b2947b79ec Link: https://lkml.kernel.org/r/20230628104852.3391651-3-dhowells@redhat.com Fixes: 1f67e6d0b188 ("fscache: Provide a function to note the release of a page") Fixes: 047487c947e8 ("cachefiles: Implement the I/O routines") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Reported-by: Rohith Surabattula <rohiths.msft@gmail.com> Suggested-by: Matthew Wilcox <willy@infradead.org> Tested-by: SeongJae Park <sj@kernel.org> Cc: Daire Byrne <daire.byrne@gmail.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Steve French <sfrench@samba.org> Cc: Shyam Prasad N <nspmangalore@gmail.com> Cc: Rohith Surabattula <rohiths.msft@gmail.com> Cc: Dave Wysochanski <dwysocha@redhat.com> Cc: Dominique Martinet <asmadeus@codewreck.org> Cc: Ilya Dryomov <idryomov@gmail.com> Cc: Andreas Dilger <adilger.kernel@dilger.ca> Cc: Jingbo Xu <jefflexu@linux.alibaba.com> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Xiubo Li <xiubli@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Stable-dep-of: 1898efcdbed3 ("block: update the stable_writes flag in bdev_add") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-03Merge tag 'v6.1.64' into v6.1/standard/baseBruce Ashfield
This is the 6.1.64 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmVmHpsACgkQONu9yGCS # aT5uvw//SzcE0GImnHnfeN7iXtpFE9O0fhTxsjZCi8/HTXmGWPtQgWscd9y81bAd # EHBVr456GXqd6KuIF+03g/r/FYinwWqK375meLfaybw1vSBP+fZttrEGqz6nTnYD # yqOxw2bqgz8Xjp63UeNHD6mifpBvVtuAvzrfO1E2Ie/U1OU2uKdjRRv0iijKNeWN # liOYTXaddIkVfZR0z6dVTl0hb5dPWsxNmF77kfVpKz4ALIHJcO13DlUuKtQz6Sb6 # 0ElmJpuonHuUxHzb8e9LLsFy3IvbBqomSscwcd0tngtdUTzhMYFIZLjg2+WQ9Ovq # raMGqvS/bKsoyoTBNKL83QB2NyXQb3vkfL0NgLsq9IwDl+r96mP9ctANYGwSjhND # o/4sa/fbMFzeInA8Rzh7i56RCNstOBKApJPhBzWuY0f/6b1BZpvZaONyX3fFksWO # dMeYT16GgO4lhQXnG3O6mtDT8eoZ1fLf7ZdGEZ2NktcOzXYelNc4aXJke7qdlIop # CVxM+Ur+juj+DJymo59a6baXjEgIROdHq83N3CZwetGviPHneGqgYc0K7ETtA33H # sH/0KGYAT8SzzjMlnXB0lpjp68WViJfzzo9Wxdf2aDZbL3SdI14GPKMUeDqqeSyU # 8bB2Hb4ItccRFW9RriiE3BPGnLGu7PDTkn5TgXDG/bDX54Cb5DQ= # =YPzI # -----END PGP SIGNATURE----- # gpg: Signature made Tue 28 Nov 2023 12:08:43 PM EST # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2023-11-28NFSv4.1: fix SP4_MACH_CRED protection for pnfs IOOlga Kornievskaia
[ Upstream commit 5cc7688bae7f0757c39c1d3dfdd827b724061067 ] If the client is doing pnfs IO and Kerberos is configured and EXCHANGEID successfully negotiated SP4_MACH_CRED and WRITE/COMMIT are on the list of state protected operations, then we need to make sure to choose the DS's rpc_client structure instead of the MDS's one. Fixes: fb91fb0ee7b2 ("NFS: Move call to nfs4_state_protect_write() to nfs4_write_setup()") Signed-off-by: Olga Kornievskaia <kolga@netapp.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-28NFSv4.1: fix handling NFS4ERR_DELAY when testing for session trunkingOlga Kornievskaia
[ Upstream commit 6bd1a77dc72dea0b0d8b6014f231143984d18f6d ] Currently when client sends an EXCHANGE_ID for a possible trunked connection, for any error that happened, the trunk will be thrown out. However, an NFS4ERR_DELAY is a transient error that should be retried instead. Fixes: e818bd085baf ("NFSv4.1 remove xprt from xprt_switch if session trunking test fails") Signed-off-by: Olga Kornievskaia <kolga@netapp.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-27Merge tag 'v6.1.60' into v6.1/standard/baseBruce Ashfield
This is the 6.1.60 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmU45+gACgkQONu9yGCS # aT67Fg/+JXLZacsN1s1C7cuYg6tLWmjChp+wTOmwbM/DAbS65Iteb98XqaFBIdVN # wipBmpT2sLAOUZlLQW4y8lS4/btqcjshcySW9KUhxOkxNuYNjIUcbAzH4ICuxs59 # L6/JAawS53i1dDVeSn8GvcjjD4Vf6bcWpArIyw0zd5bXMP8zw+SIfAuvAMO4ZGWq # +xS/q+sK3rMo5oatL1u7D0qFuOaq1QLnWjezjtN3IuCj8cTleXecdsEvXpudPZkG # +x/RoNdb/n8c/X3OrzOWcpEt7eFsg9Jo3xgm4WNtrAtBn9+AfI5zZilSTclVYuWb # bIAzphyt95vhTccyRC5CNHVxwYqIa4wtkPKn8HnUIm0qh0/w8wZp9ILuFXWSJxAE # SjmrCGqEUEw1J2CWacXB30RMXL1Od1YjXHqQ4kYs3z2re/c/JEFA86fRsR6mhi5D # iPn8NLSuw/idWFGqHLFO1H1aqnKeRVU8uLJaUr2UnoQUmPGdZwioeNIIYu7TsC2H # 4tj7VkYw/Gj/tgswdILrhCnWMp/sok1HcopFQ5EgTWCaRlbOcUN3RFVlXGQxTjbt # 3sEZS5Wd++lu4sZqLX5aM5y9pl+0pXr/5bTxaRPEJ+YQSkXU8UKxHS0ZG7ym43ht # OhXQdMH2D8dRd0zhrjxFYUxB8z2V8DMou8le48r3UpNG2RAjm9s= # =4KJe # -----END PGP SIGNATURE----- # gpg: Signature made Wed 25 Oct 2023 06:03:20 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2023-10-25nfs42: client needs to strip file mode's suid/sgid bit after ALLOCATE opDai Ngo
commit f588d72bd95f748849685412b1f0c7959ca228cf upstream. The Linux NFS server strips the SUID and SGID from the file mode on ALLOCATE op. Modify _nfs42_proc_fallocate to add NFS_INO_REVAL_FORCED to nfs_set_cache_invalid's argument to force update of the file mode suid/sgid bit. Suggested-by: Trond Myklebust <trondmy@hammerspace.com> Signed-off-by: Dai Ngo <dai.ngo@oracle.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Tested-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25NFSv4.1: fixup use EXCHGID4_FLAG_USE_PNFS_DS for DS serverOlga Kornievskaia
commit 379e4adfddd6a2f95a4f2029b8ddcbacf92b21f9 upstream. This patches fixes commit 51d674a5e488 "NFSv4.1: use EXCHGID4_FLAG_USE_PNFS_DS for DS server", purpose of that commit was to mark EXCHANGE_ID to the DS with the appropriate flag. However, connection to MDS can return both EXCHGID4_FLAG_USE_PNFS_DS and EXCHGID4_FLAG_USE_PNFS_MDS set but previous patch would only remember the USE_PNFS_DS and for the 2nd EXCHANGE_ID send that to the MDS. Instead, just mark the pnfs path exclusively. Fixes: 51d674a5e488 ("NFSv4.1: use EXCHGID4_FLAG_USE_PNFS_DS for DS server") Signed-off-by: Olga Kornievskaia <kolga@netapp.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25pNFS/flexfiles: Check the layout validity in ff_layout_mirror_prepare_statsTrond Myklebust
commit e1c6cfbb3bd1377e2ddcbe06cf8fb1ec323ea7d3 upstream. Ensure that we check the layout pointer and validity after dereferencing it in ff_layout_mirror_prepare_stats. Fixes: 08e2e5bc6c9a ("pNFS/flexfiles: Clean up layoutstats") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25pNFS: Fix a hang in nfs4_evict_inode()Trond Myklebust
commit f63955721a8020e979b99cc417dcb6da3106aa24 upstream. We are not allowed to call pnfs_mark_matching_lsegs_return() without also holding a reference to the layout header, since doing so could lead to the reference count going to zero when we call pnfs_layout_remove_lseg(). This again can lead to a hang when we get to nfs4_evict_inode() and are unable to clear the layout pointer. pnfs_layout_return_unused_byserver() is guilty of this behaviour, and has been seen to trigger the refcount warning prior to a hang. Fixes: b6d49ecd1081 ("NFSv4: Fix a pNFS layout related use-after-free race when freeing the inode") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-23Merge tag 'v6.1.58' into v6.1/standard/baseBruce Ashfield
This is the 6.1.58 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUsFDAACgkQONu9yGCS # aT4zYA//WvfMHfRodo8tbfkAQJpSBm8YSTbw9qEaElFPkuhmDXoiifKK9dyGDBOj # OyhDSB8gCdM1yfkpxUCwlKES5neqwPZz+uWDdk/gKuzVOZvAIS8j4lM9msv6ns9j # GCW6hH37nXaSa+fWzH7bQ/mZxX/aauSS4tUOaqaoeF14LkfkNWX+Z0m1WrDK6CXg # 0pd9KBDpF7ykuFAS0+9rPYzjZQuPcYo4DBWl8/aNS8LhUmPSnt2HYPg89k2ag4Kv # SrOUjAGZtJgih1ipPqi/sDBuBIZPi7IkoxEYA6oB67Tk1EwU9BSVV2p1+1kDtgZI # 9Xti/v/m0tVs6ceA1rIbdOaUqargbxWF7EdUBEp+j6QkcniJ7r9ek0RZF+y7X5aM # Xl3ZjSu2fYw2/6zTQVG3q+f25afU6+Th4MhnN9oHOW9JE3eehIYaJt5W73SpAd96 # jfZpYqpVHHqmURHXKdckoCZ3lDaAXq674lwFzEpF0kGd4aDjCcUdXqYf4P0/b4w+ # cYVQiQRQtuCkbp3QGnwIg/VVI0dD+R0wOZ+7mAq7CF6ORpzlgHJIrZNp+SEhQhw8 # ZI8y2Yb9nRE1NmmO024RHt+dRiUXKlah8e3XyKYUtbogJgS2dC387+A0Mt1BpA0p # DH2eUXU1S8CSA+rCLJIMaGECgfDHyI2MeVaqo6+eeptJCW0sibE= # =kcuO # -----END PGP SIGNATURE----- # gpg: Signature made Sun 15 Oct 2023 12:32:48 PM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2023-10-15Revert "NFS: Fix error handling for O_DIRECT write scheduling"Greg Kroah-Hartman
This reverts commit f16fd0b11f0f4d41846b5102b1656ea1fc9ac7a0 which is commit 954998b60caa8f2a3bf3abe490de6f08d283687a upstream. There are reported NFS problems in the 6.1.56 release, so revert a set of NFS patches to hopefully resolve the issue. Reported-by: poester <poester@internetbrands.com> Link: https://lore.kernel.org/r/20231012165439.137237-2-kernel@linuxace.com Reported-by: Daniel Díaz <daniel.diaz@linaro.org> Link: https://lore.kernel.org/r/2023100755-livestock-barcode-fe41@gregkh Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-15Revert "NFS: Fix O_DIRECT locking issues"Greg Kroah-Hartman
This reverts commit 4d98038e5bd939bd13cc4e602dfe60cd5110efa8 which is commit 7c6339322ce0c6128acbe36aacc1eeb986dd7bf1 upstream. There are reported NFS problems in the 6.1.56 release, so revert a set of NFS patches to hopefully resolve the issue. Reported-by: poester <poester@internetbrands.com> Link: https://lore.kernel.org/r/20231012165439.137237-2-kernel@linuxace.com Reported-by: Daniel Díaz <daniel.diaz@linaro.org> Link: https://lore.kernel.org/r/2023100755-livestock-barcode-fe41@gregkh Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-15Revert "NFS: More O_DIRECT accounting fixes for error paths"Greg Kroah-Hartman
This reverts commit 1f49386d67792424028acfe781d466b010f8fa3f which is commit 8982f7aff39fb526aba4441fff2525fcedd5e1a3 upstream. There are reported NFS problems in the 6.1.56 release, so revert a set of NFS patches to hopefully resolve the issue. Reported-by: poester <poester@internetbrands.com> Link: https://lore.kernel.org/r/20231012165439.137237-2-kernel@linuxace.com Reported-by: Daniel Díaz <daniel.diaz@linaro.org> Link: https://lore.kernel.org/r/2023100755-livestock-barcode-fe41@gregkh Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-15Revert "NFS: Use the correct commit info in nfs_join_page_group()"Greg Kroah-Hartman
This reverts commit d4729af1c73cfacb64facda3d196e25940f0e7a5 which is commit b193a78ddb5ee7dba074d3f28dc050069ba083c0 upstream. There are reported NFS problems in the 6.1.56 release, so revert a set of NFS patches to hopefully resolve the issue. Reported-by: poester <poester@internetbrands.com> Link: https://lore.kernel.org/r/20231012165439.137237-2-kernel@linuxace.com Reported-by: Daniel Díaz <daniel.diaz@linaro.org> Link: https://lore.kernel.org/r/2023100755-livestock-barcode-fe41@gregkh Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-15Revert "NFS: More fixes for nfs_direct_write_reschedule_io()"Greg Kroah-Hartman
This reverts commit edd1f06145101dab83497806bb6162641255ef50 which is commit b11243f720ee5f9376861099019c8542969b6318 upstream. There are reported NFS problems in the 6.1.56 release, so revert a set of NFS patches to hopefully resolve the issue. Reported-by: poester <poester@internetbrands.com> Link: https://lore.kernel.org/r/20231012165439.137237-2-kernel@linuxace.com Reported-by: Daniel Díaz <daniel.diaz@linaro.org> Link: https://lore.kernel.org/r/2023100755-livestock-barcode-fe41@gregkh Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-11Merge tag 'v6.1.57' into v6.1/standard/baseBruce Ashfield
This is the 6.1.57 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUlrb4ACgkQONu9yGCS # aT4b+hAAgvFC6P+XmyyNXJ9ISHLkgSlcIAdatb+qeOCUtdiWHqfxIha13FdnCdhL # WS2c/O9ORfAzjFwnYWF6LBwH8ArxRSkAXrGCMuCkEFBP3cG/j2HD+XLAAYEuBjjb # sf1fw8e8VSgaPEOnwXie5rTfAY4VnZKEtZjAxjyIQnJKVVKfxQRb8CyaWDPzPD0Z # tL/iABt7UWNHZayHTHsh0YhF2UhXtOjHinWigEarcZQEvOB2qRQtFl71cnqosi+t # 3ZRZzepH7/Fx3v6/H/6PNq+GSI/ZzhOiCQolVV5YcMGHXsW9cP6arjLUxco5pzpk # pEg0vdMq47JOZYQ2pIewG4t7+NLmFIxCRFnKQVbxeFNSY9c1jhd8g5lhx9YEXwjT # BzMtV5DnZoaoMdq2P1STw/+RVYrDI1Lm6jqfgw/D27b7LzQ13VsGM9BJ1rCs8Hm7 # UhWyjwFcgo0vhpfML1RF0RtT9Mo5SOnpGPfpbFdjg8jdXlGknNH0QsH+EY/BpF8l # h77P5BvoNIjsIN3B1YunfXtFXhx3h0sI8zZrqHR+zhOeWGsXcqQ5mZ/lYdYKkKuH # R8LRB7shPndF4xdRX0uRXwomcXhs+60eA5xEvE9u0CqqdpXfQN5oTwixfCm2C8MS # O5Fc7hfvK11XtR3ja+y3KRhiNG3YsfW2PXnlOfZxMZ6iPqXtA/o= # =5/pn # -----END PGP SIGNATURE----- # gpg: Signature made Tue 10 Oct 2023 04:02:06 PM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2023-10-10NFSv4: Fix a nfs4_state_manager() raceTrond Myklebust
[ Upstream commit ed1cc05aa1f7fe8197d300e914afc28ab9818f89 ] If the NFS4CLNT_RUN_MANAGER flag got set just before we cleared NFS4CLNT_MANAGER_RUNNING, then we might have won the race against nfs4_schedule_state_manager(), and are responsible for handling the recovery situation. Fixes: aeabb3c96186 ("NFSv4: Fix a NFSv4 state manager deadlock") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-10Revert "NFSv4: Retry LOCK on OLD_STATEID during delegation return"Benjamin Coddington
[ Upstream commit 5b4a82a0724af1dfd1320826e0266117b6a57fbd ] Olga Kornievskaia reports that this patch breaks NFSv4.0 state recovery. It also introduces additional complexity in the error paths for cases not related to the original problem. Let's revert it for now, and address the original problem in another manner. This reverts commit f5ea16137a3fa2858620dc9084466491c128535f. Fixes: f5ea16137a3f ("NFSv4: Retry LOCK on OLD_STATEID during delegation return") Reported-by: Kornievskaia, Olga <Olga.Kornievskaia@netapp.com> Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-10NFSv4: Fix a state manager thread deadlock regressionTrond Myklebust
[ Upstream commit 956fd46f97d238032cb5fa4771cdaccc6e760f9a ] Commit 4dc73c679114 reintroduces the deadlock that was fixed by commit aeabb3c96186 ("NFSv4: Fix a NFSv4 state manager deadlock") because it prevents the setup of new threads to handle reboot recovery, while the older recovery thread is stuck returning delegations. Fixes: 4dc73c679114 ("NFSv4: keep state manager thread active if swap is enabled") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-10NFS: rename nfs_client_kset to nfs_ksetBenjamin Coddington
[ Upstream commit 8b18a2edecc0741b0eecf8b18fdb356a0f8682de ] Be brief and match the subsystem name. There's no need to distinguish this kset variable from the server. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Stable-dep-of: 956fd46f97d2 ("NFSv4: Fix a state manager thread deadlock regression") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-10NFS: Cleanup unused rpc_clnt variableBenjamin Coddington
[ Upstream commit e025f0a73f6acb920d86549b2177a5883535421d ] The root rpc_clnt is not used here, clean it up. Fixes: 4dc73c679114 ("NFSv4: keep state manager thread active if swap is enabled") Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Reviewed-by: NeilBrown <neilb@suse.de> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Stable-dep-of: 956fd46f97d2 ("NFSv4: Fix a state manager thread deadlock regression") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-08Merge tag 'v6.1.56' into v6.1/standard/baseBruce Ashfield
This is the 6.1.56 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUgBFoACgkQONu9yGCS # aT72mg//cKCMEO3xf8XSRfLCq0FlSF5yxyS8T2XZjM8uoHAq+llDq8YFd0kW65EG # Ra3YmVfl3BXEI2m6e8tXAnCFyaqelR3ZNQPIT3Mnxzg8HD8QRzL/jMOe6+EdOwf+ # 521Q+bpzBQvrhzyl0yVWK6l9gm+G5qj7f/t1yw9e5q+WOoyVmfGczaqhNi8y7IoN # 9s3sQ9R0pJIbtkA608QyQ+WDcj5qdwxWL6Okd6vnWM0wOXepX+SZ7BC3L1NTPqx1 # +jJLhLBeeTl0EBVjigdTFhF/Dyi9fCJrjUcgWYdYchxz1AnwLDVhAdZxPG9yPg/s # tzQVui1BhfAjFIoifqZ876ESskd9zaTAWjWDPHctzxjd7qv8yqi+hUoDvlzMMngT # wDhb5hpTn2FMsrmZDjGBlrS3kv5Bj3eBZgT8GahXFhwXKSWOr9QHy1njPOHfUWDg # 0fF2jOnadR61UA4CjW6sxsrC/MlGA7CkLGxiJGTrji9qUy0tgpSKwVpRhsBOR6XW # 2oeeX4avEaZvuV9sW9k6cjz47PE9o3p0IPqvV380FuiTSH6pepD1rM3RJxwJMT8I # KEbZkvKIMp6onKMsNNLmNdGp5xGQsk1ax2v2PWFZvOhLvrEHUwdi/SLE/Ur1cyNL # xEQB1JXMn2Dr4NtWWrwsAIEPyzFvGjwx25MrgP59Not8EJQJRAc= # =Ra3D # -----END PGP SIGNATURE----- # gpg: Signature made Fri 06 Oct 2023 08:58:02 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2023-10-06NFSv4.1: fix zero value filehandle in post open getattrOlga Kornievskaia
[ Upstream commit 4506f23e117161a20104c8fa04f33e1ca63c26af ] Currently, if the OPEN compound experiencing an error and needs to get the file attributes separately, it will send a stand alone GETATTR but it would use the filehandle from the results of the OPEN compound. In case of the CLAIM_FH OPEN, nfs_openres's fh is zero value. That generate a GETATTR that's sent with a zero value filehandle, and results in the server returning an error. Instead, for the CLAIM_FH OPEN, take the filehandle that was used in the PUTFH of the OPEN compound. Signed-off-by: Olga Kornievskaia <kolga@netapp.com> Reviewed-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06NFSv4.1: fix pnfs MDS=DS session trunkingOlga Kornievskaia
[ Upstream commit 806a3bc421a115fbb287c1efce63a48c54ee804b ] Currently, when GETDEVICEINFO returns multiple locations where each is a different IP but the server's identity is same as MDS, then nfs4_set_ds_client() finds the existing nfs_client structure which has the MDS's max_connect value (and if it's 1), then the 1st IP on the DS's list will get dropped due to MDS trunking rules. Other IPs would be added as they fall under the pnfs trunking rules. For the list of IPs the 1st goes thru calling nfs4_set_ds_client() which will eventually call nfs4_add_trunk() and call into rpc_clnt_test_and_add_xprt() which has the check for MDS trunking. The other IPs (after the 1st one), would call rpc_clnt_add_xprt() which doesn't go thru that check. nfs4_add_trunk() is called when MDS trunking is happening and it needs to enforce the usage of max_connect mount option of the 1st mount. However, this shouldn't be applied to pnfs flow. Instead, this patch proposed to treat MDS=DS as DS trunking and make sure that MDS's max_connect limit does not apply to the 1st IP returned in the GETDEVICEINFO list. It does so by marking the newly created client with a new flag NFS_CS_PNFS which then used to pass max_connect value to use into the rpc_clnt_test_and_add_xprt() instead of the existing rpc client's max_connect value set by the MDS connection. For example, mount was done without max_connect value set so MDS's rpc client has cl_max_connect=1. Upon calling into rpc_clnt_test_and_add_xprt() and using rpc client's value, the caller passes in max_connect value which is previously been set in the pnfs path (as a part of handling GETDEVICEINFO list of IPs) in nfs4_set_ds_client(). However, when NFS_CS_PNFS flag is not set and we know we are doing MDS trunking, comparing a new IP of the same server, we then set the max_connect value to the existing MDS's value and pass that into rpc_clnt_test_and_add_xprt(). Fixes: dc48e0abee24 ("SUNRPC enforce creation of no more than max_connect xprts") Signed-off-by: Olga Kornievskaia <kolga@netapp.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06NFSv4.1: use EXCHGID4_FLAG_USE_PNFS_DS for DS serverOlga Kornievskaia
[ Upstream commit 51d674a5e4889f1c8e223ac131cf218e1631e423 ] After receiving the location(s) of the DS server(s) in the GETDEVINCEINFO, create the request for the clientid to such server and indicate that the client is connecting to a DS. Signed-off-by: Olga Kornievskaia <kolga@netapp.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Stable-dep-of: 806a3bc421a1 ("NFSv4.1: fix pnfs MDS=DS session trunking") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06NFS/pNFS: Report EINVAL errors from connect() to the serverTrond Myklebust
[ Upstream commit dd7d7ee3ba2a70d12d02defb478790cf57d5b87b ] With IPv6, connect() can occasionally return EINVAL if a route is unavailable. If this happens during I/O to a data server, we want to report it using LAYOUTERROR as an inability to connect. Fixes: dd52128afdde ("NFSv4.1/pnfs Ensure flexfiles reports all connection related errors") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06NFS: More fixes for nfs_direct_write_reschedule_io()Trond Myklebust
[ Upstream commit b11243f720ee5f9376861099019c8542969b6318 ] Ensure that all requests are put back onto the commit list so that they can be rescheduled. Fixes: 4daaeba93822 ("NFS: Fix nfs_direct_write_reschedule_io()") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06NFS: Use the correct commit info in nfs_join_page_group()Trond Myklebust
[ Upstream commit b193a78ddb5ee7dba074d3f28dc050069ba083c0 ] Ensure that nfs_clear_request_commit() updates the correct counters when it removes them from the commit list. Fixes: ed5d588fe47f ("NFS: Try to join page groups before an O_DIRECT retransmission") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06NFS: More O_DIRECT accounting fixes for error pathsTrond Myklebust
[ Upstream commit 8982f7aff39fb526aba4441fff2525fcedd5e1a3 ] If we hit a fatal error when retransmitting, we do need to record the removal of the request from the count of written bytes. Fixes: 031d73ed768a ("NFS: Fix O_DIRECT accounting of number of bytes read/written") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06NFS: Fix O_DIRECT locking issuesTrond Myklebust
[ Upstream commit 7c6339322ce0c6128acbe36aacc1eeb986dd7bf1 ] The dreq fields are protected by the dreq->lock. Fixes: 954998b60caa ("NFS: Fix error handling for O_DIRECT write scheduling") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06NFS: Fix error handling for O_DIRECT write schedulingTrond Myklebust
[ Upstream commit 954998b60caa8f2a3bf3abe490de6f08d283687a ] If we fail to schedule a request for transmission, there are 2 possibilities: 1) Either we hit a fatal error, and we just want to drop the remaining requests on the floor. 2) We were asked to try again, in which case we should allow the outstanding RPC calls to complete, so that we can recoalesce requests and try again. Fixes: d600ad1f2bdb ("NFS41: pop some layoutget errors to application") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-25Merge tag 'v6.1.54' into v6.1/standard/baseBruce Ashfield
This is the 6.1.54 stable release # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUJd8EACgkQONu9yGCS # aT7crQ//ZsUDeoTMsQBU6lB2g32LODO3jVPXdGdRjLvpLVMMnKXXwl3uTC20CQ23 # mtlN1mku6OtyPHgorKK9nJoNVTG78v0wXL8iCe5GHEKri45FwmcKlCxtIqboGCcg # bpRkLqfZ/cNVFeV/81n7kMFI/GHST2qym/lJfUkK0BIewXOrJozHMyCriLhG5uc/ # XPmXN3LlGmT7Gb2KwJeAgJ9IWrVu5ZEWH6CnpjnLPXMA3FGJiBiYPeGaWRsrdjth # MvACPXKPu5tKAmEs6eyAhB1YbXbswKviDuY+YHeTMoOVYCfJY29VQTI16F6HBGeM # XVCo1AovZV+B9OrgnzYA8x5iZIKCdk/PzUhBi+uUb3nLJhGpD8ha7wOuBjehINeo # 22YY+7fmB7lZVSAe14hDH7GjKNdYpxntPVpWCMa1yoCUtqKB1O44/10mj0OjZ5j4 # EXKXIe6ho+0Uatubd+3hWRXimz4jzlp7UY1QM9ge5MGp0wOmdLu5Q91T70CrCEJO # RxXZSkHDKGxokXubl4oF0bYYpB1kRVgsNEc4H5i2k+OheyDBmVv3vRPMzT/2yim/ # BEqwX6x2sE7kvbsyCO5VxIIVsnAystJEKzdVlRxmrcqkV0FCdqHjwZ9cr0mpqOse # ogdnQgXQpaGUyhdYcpo4U9f+WGi5AHXs3IMbKQN4SDZGDgJHrss= # =XhWe # -----END PGP SIGNATURE----- # gpg: Signature made Tue 19 Sep 2023 06:28:17 AM EDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Can't check signature: No public key
2023-09-19NFSv4/pnfs: minor fix for cleanup path in nfs4_get_device_infoFedor Pchelkin
commit 96562c45af5c31b89a197af28f79bfa838fb8391 upstream. It is an almost improbable error case but when page allocating loop in nfs4_get_device_info() fails then we should only free the already allocated pages, as __free_page() can't deal with NULL arguments. Found by Linux Verification Center (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Reviewed-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-19NFS: Fix a potential data corruptionTrond Myklebust
commit 88975a55969e11f26fe3846bf4fbf8e7dc8cbbd4 upstream. We must ensure that the subrequests are joined back into the head before we can retransmit a request. If the head was not on the commit lists, because the server wrote it synchronously, we still need to add it back to the retransmission list. Add a call that mirrors the effect of nfs_cancel_remove_inode() for O_DIRECT. Fixes: ed5d588fe47f ("NFS: Try to join page groups before an O_DIRECT retransmission") Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-06-26 09:13:35 +0000