<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/nfs, branch linux-6.10.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.10.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.10.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2024-10-04T14:33:41Z</updated>
<entry>
<title>nfs: fix memory leak in error path of nfs4_do_reclaim</title>
<updated>2024-10-04T14:33:41Z</updated>
<author>
<name>Li Lingfeng</name>
</author>
<published>2024-09-04T12:34:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=68ee58f3a06757f0d6598eb2c0d0826cebb4b8b4'/>
<id>urn:sha1:68ee58f3a06757f0d6598eb2c0d0826cebb4b8b4</id>
<content type='text'>
commit 8f6a7c9467eaf39da4c14e5474e46190ab3fb529 upstream.

Commit c77e22834ae9 ("NFSv4: Fix a potential sleep while atomic in
nfs4_do_reclaim()") separate out the freeing of the state owners from
nfs4_purge_state_owners() and finish it outside the rcu lock.
However, the error path is omitted. As a result, the state owners in
"freeme" will not be released.
Fix it by adding freeing in the error path.

Fixes: c77e22834ae9 ("NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim()")
Signed-off-by: Li Lingfeng &lt;lilingfeng3@huawei.com&gt;
Cc: stable@vger.kernel.org # v5.3+
Signed-off-by: Anna Schumaker &lt;anna.schumaker@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>NFS: Avoid unnecessary rescanning of the per-server delegation list</title>
<updated>2024-09-18T17:25:12Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2024-08-21T18:05:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a23c1b9a76f8e7ec975918b25bef74e7631b422a'/>
<id>urn:sha1:a23c1b9a76f8e7ec975918b25bef74e7631b422a</id>
<content type='text'>
[ Upstream commit f92214e4c312f6ea9d78650cc6291d200f17abb6 ]

If the call to nfs_delegation_grab_inode() fails, we will not have
dropped any locks that require us to rescan the list.

Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Reviewed-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFSv4: Fix clearing of layout segments in layoutreturn</title>
<updated>2024-09-18T17:25:12Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2024-08-21T18:05:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f2331b87fdaf5c2eecc88fcfbaacb81c5a79b991'/>
<id>urn:sha1:f2331b87fdaf5c2eecc88fcfbaacb81c5a79b991</id>
<content type='text'>
[ Upstream commit d72b7963115bea971a28eaa2cb76722c023f9fdf ]

Make sure that we clear the layout segments in cases where we see a
fatal error, and also in the case where the layout is invalid.

Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Reviewed-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFSv4: Add missing rescheduling points in nfs_client_return_marked_delegations</title>
<updated>2024-09-12T09:13:05Z</updated>
<author>
<name>Trond Myklebust</name>
</author>
<published>2024-08-21T18:05:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f9f0b593baeff92766d424e97112a63b4f25b621'/>
<id>urn:sha1:f9f0b593baeff92766d424e97112a63b4f25b621</id>
<content type='text'>
[ Upstream commit a017ad1313fc91bdf235097fd0a02f673fc7bb11 ]

We're seeing reports of soft lockups when iterating through the loops,
so let's add rescheduling points.

Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Reviewed-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nfs: pass explicit offset/count to trace events</title>
<updated>2024-08-03T07:00:05Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2024-07-11T07:17:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=387e6e9d110250946df4d4ebef9c2def5c7a4722'/>
<id>urn:sha1:387e6e9d110250946df4d4ebef9c2def5c7a4722</id>
<content type='text'>
[ Upstream commit fada32ed6dbc748f447c8d050a961b75d946055a ]

nfs_folio_length is unsafe to use without having the folio locked and a
check for a NULL -&gt;f_mapping that protects against truncations and can
lead to kernel crashes.  E.g. when running xfstests generic/065 with
all nfs trace points enabled.

Follow the model of the XFS trace points and pass in an explіcit offset
and length.  This has the additional benefit that these values can
be more accurate as some of the users touch partial folio ranges.

Fixes: eb5654b3b89d ("NFS: Enable tracing of nfs_invalidate_folio() and nfs_launder_folio()")
Reported-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFSv4.1 another fix for EXCHGID4_FLAG_USE_PNFS_DS for DS server</title>
<updated>2024-08-03T07:00:04Z</updated>
<author>
<name>Olga Kornievskaia</name>
</author>
<published>2024-06-24T13:28:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4ebf5bfd3400143c9277db1c96bdcbb6b9465912'/>
<id>urn:sha1:4ebf5bfd3400143c9277db1c96bdcbb6b9465912</id>
<content type='text'>
[ Upstream commit 4840c00003a2275668a13b82c9f5b1aed80183aa ]

Previously in order to mark the communication with the DS server,
we tried to use NFS_CS_DS in cl_flags. However, this flag would
only be saved for the DS server and in case where DS equals MDS,
the client would not find a matching nfs_client in nfs_match_client
that represents the MDS (but is also a DS).

Instead, don't rely on the NFS_CS_DS but instead use NFS_CS_PNFS.

Fixes: 379e4adfddd6 ("NFSv4.1: fixup use EXCHGID4_FLAG_USE_PNFS_DS for DS server")
Signed-off-by: Olga Kornievskaia &lt;kolga@netapp.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nfs: drop the incorrect assertion in nfs_swap_rw()</title>
<updated>2024-06-25T03:52:11Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2024-06-18T06:56:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=54e7d59841dab977f6cb1183d658b1b82c9f4e94'/>
<id>urn:sha1:54e7d59841dab977f6cb1183d658b1b82c9f4e94</id>
<content type='text'>
Since commit 2282679fb20b ("mm: submit multipage write for SWP_FS_OPS
swap-space"), we can plug multiple pages then unplug them all together. 
That means iov_iter_count(iter) could be way bigger than PAGE_SIZE, it
actually equals the size of iov_iter_npages(iter, INT_MAX).

Note this issue has nothing to do with large folios as we don't support
THP_SWPOUT to non-block devices.

[v-songbaohua@oppo.com: figure out the cause and correct the commit message]
Link: https://lkml.kernel.org/r/20240618065647.21791-1-21cnbao@gmail.com
Fixes: 2282679fb20b ("mm: submit multipage write for SWP_FS_OPS swap-space")
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Barry Song &lt;v-songbaohua@oppo.com&gt;
Closes: https://lore.kernel.org/linux-mm/20240617053201.GA16852@lst.de/
Reviewed-by: Martin Wege &lt;martin.l.wege@gmail.com&gt;
Cc: NeilBrown &lt;neilb@suse.de&gt;
Cc: Anna Schumaker &lt;anna@kernel.org&gt;
Cc: Steve French &lt;sfrench@samba.org&gt;
Cc: Trond Myklebust &lt;trondmy@kernel.org&gt;
Cc: Chuanhua Han &lt;hanchuanhua@oppo.com&gt;
Cc: Ryan Roberts &lt;ryan.roberts@arm.com&gt;
Cc: Chris Li &lt;chrisl@kernel.org&gt;
Cc: "Huang, Ying" &lt;ying.huang@intel.com&gt;
Cc: Jeff Layton &lt;jlayton@kernel.org&gt;
Cc: Matthew Wilcox &lt;willy@infradead.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'nfs-for-6.10-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs</title>
<updated>2024-06-13T18:07:32Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2024-06-13T18:07:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fd88e181d80579afbc56b9d69ef884c81abc2df0'/>
<id>urn:sha1:fd88e181d80579afbc56b9d69ef884c81abc2df0</id>
<content type='text'>
Pull NFS client fixes from Trond Myklebust:
 "Bugfixes:
   - NFSv4.2: Fix a memory leak in nfs4_set_security_label
   - NFSv2/v3: abort nfs_atomic_open_v23 if the name is too long.
   - NFS: Add appropriate memory barriers to the sillyrename code
   - Propagate readlink errors in nfs_symlink_filler
   - NFS: don't invalidate dentries on transient errors
   - NFS: fix unnecessary synchronous writes in random write workloads
   - NFSv4.1: enforce rootpath check when deciding whether or not to trunk

  Other:
   - Change email address for Trond Myklebust due to email server concerns"

* tag 'nfs-for-6.10-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
  NFS: add barriers when testing for NFS_FSDATA_BLOCKED
  SUNRPC: return proper error from gss_wrap_req_priv
  NFSv4.1 enforce rootpath check in fs_location query
  NFS: abort nfs_atomic_open_v23 if name is too long.
  nfs: don't invalidate dentries on transient errors
  nfs: Avoid flushing many pages with NFS_FILE_SYNC
  nfs: propagate readlink errors in nfs_symlink_filler
  MAINTAINERS: Change email address for Trond Myklebust
  NFSv4: Fix memory leak in nfs4_set_security_label
</content>
</entry>
<entry>
<title>NFS: add barriers when testing for NFS_FSDATA_BLOCKED</title>
<updated>2024-05-30T20:17:12Z</updated>
<author>
<name>NeilBrown</name>
</author>
<published>2024-05-28T03:27:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=99bc9f2eb3f79a2b4296d9bf43153e1d10ca50d3'/>
<id>urn:sha1:99bc9f2eb3f79a2b4296d9bf43153e1d10ca50d3</id>
<content type='text'>
dentry-&gt;d_fsdata is set to NFS_FSDATA_BLOCKED while unlinking or
renaming-over a file to ensure that no open succeeds while the NFS
operation progressed on the server.

Setting dentry-&gt;d_fsdata to NFS_FSDATA_BLOCKED is done under -&gt;d_lock
after checking the refcount is not elevated.  Any attempt to open the
file (through that name) will go through lookp_open() which will take
-&gt;d_lock while incrementing the refcount, we can be sure that once the
new value is set, __nfs_lookup_revalidate() *will* see the new value and
will block.

We don't have any locking guarantee that when we set -&gt;d_fsdata to NULL,
the wait_var_event() in __nfs_lookup_revalidate() will notice.
wait/wake primitives do NOT provide barriers to guarantee order.  We
must use smp_load_acquire() in wait_var_event() to ensure we look at an
up-to-date value, and must use smp_store_release() before wake_up_var().

This patch adds those barrier functions and factors out
block_revalidate() and unblock_revalidate() far clarity.

There is also a hypothetical bug in that if memory allocation fails
(which never happens in practice) we might leave -&gt;d_fsdata locked.
This patch adds the missing call to unblock_revalidate().

Reported-and-tested-by: Richard Kojedzinszky &lt;richard+debian+bugreport@kojedz.in&gt;
Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071501
Fixes: 3c59366c207e ("NFS: don't unhash dentry during unlink/rename")
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
</content>
</entry>
<entry>
<title>NFSv4.1 enforce rootpath check in fs_location query</title>
<updated>2024-05-30T20:12:43Z</updated>
<author>
<name>Olga Kornievskaia</name>
</author>
<published>2024-05-29T19:44:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=28568c906c1bb5f7560e18082ed7d6295860f1c2'/>
<id>urn:sha1:28568c906c1bb5f7560e18082ed7d6295860f1c2</id>
<content type='text'>
In commit 4ca9f31a2be66 ("NFSv4.1 test and add 4.1 trunking transport"),
we introduce the ability to query the NFS server for possible trunking
locations of the existing filesystem. However, we never checked the
returned file system path for these alternative locations. According
to the RFC, the server can say that the filesystem currently known
under "fs_root" of fs_location also resides under these server
locations under the following "rootpath" pathname. The client cannot
handle trunking a filesystem that reside under different location
under different paths other than what the main path is. This patch
enforces the check that fs_root path and rootpath path in fs_location
reply is the same.

Fixes: 4ca9f31a2be6 ("NFSv4.1 test and add 4.1 trunking transport")
Signed-off-by: Olga Kornievskaia &lt;kolga@netapp.com&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
</content>
</entry>
</feed>
