<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/nfs, branch v6.18.21</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.21</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.21'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-19T15:08:12+00:00</updated>
<entry>
<title>nfs: return EISDIR on nfs3_proc_create if d_alias is a dir</title>
<updated>2026-03-19T15:08:12+00:00</updated>
<author>
<name>Roberto Bergantinos Corpas</name>
<email>rbergant@redhat.com</email>
</author>
<published>2026-02-19T12:04:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=203c792cb4315360d49973ae2e57feeb6d3dcf7e'/>
<id>urn:sha1:203c792cb4315360d49973ae2e57feeb6d3dcf7e</id>
<content type='text'>
[ Upstream commit 410666a298c34ebd57256fde6b24c96bd23059a2 ]

If we found an alias through nfs3_do_create/nfs_add_or_obtain
/d_splice_alias which happens to be a dir dentry, we don't return
any error, and simply forget about this alias, but the original
dentry we were adding and passed as parameter remains negative.

This later causes an oops on nfs_atomic_open_v23/finish_open since we
supply a negative dentry to do_dentry_open.

This has been observed running lustre-racer, where dirs and files are
created/removed concurrently with the same name and O_EXCL is not
used to open files (frequent file redirection).

While d_splice_alias typically returns a directory alias or NULL, we
explicitly check d_is_dir() to ensure that we don't attempt to perform
file operations (like finish_open) on a directory inode, which triggers
the observed oops.

Fixes: 7c6c5249f061 ("NFS: add atomic_open for NFSv3 to handle O_TRUNC correctly.")
Reviewed-by: Olga Kornievskaia &lt;okorniev@redhat.com&gt;
Reviewed-by: Scott Mayhew &lt;smayhew@redhat.com&gt;
Signed-off-by: Roberto Bergantinos Corpas &lt;rbergant@redhat.com&gt;
Signed-off-by: Anna Schumaker &lt;anna.schumaker@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs/nfs: Fix readdir slow-start regression</title>
<updated>2026-02-26T22:59:28+00:00</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagi@grimberg.me</email>
</author>
<published>2025-12-27T10:46:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=47d3fed638664a72b2b84f02b8ef85d7fe75c048'/>
<id>urn:sha1:47d3fed638664a72b2b84f02b8ef85d7fe75c048</id>
<content type='text'>
[ Upstream commit 42e7c876b182da65723700f6bc507a8aecb10d3b ]

Commit 580f236737d1 ("NFS: Adjust the amount of readahead
performed by NFS readdir") reduces the amount of readahead names
caching done by the client.

The downside of this approach is READDIR now may suffer from
a slow-start issue, where initially it will fetch names that fit
in a single page, then in 2, 4, 8 until the maximum supported
transfer size (usually 1M).

This patch tries to take a balanced approach between mitigating
the slow-start issue still maintaining some efficiency gains.

Fixes: 580f236737d1 ("NFS: Adjust the amount of readahead performed by NFS readdir")
Signed-off-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Anna Schumaker &lt;anna.schumaker@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pNFS: fix a missing wake up while waiting on NFS_LAYOUT_DRAIN</title>
<updated>2026-02-26T22:59:27+00:00</updated>
<author>
<name>Olga Kornievskaia</name>
<email>okorniev@redhat.com</email>
</author>
<published>2026-01-26T19:15:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=48cb99e745614fe112996d48cc49580a01865135'/>
<id>urn:sha1:48cb99e745614fe112996d48cc49580a01865135</id>
<content type='text'>
[ Upstream commit 5248d8474e594d156bee1ed10339cc16e207a28b ]

It is possible to have a task get stuck on waiting on the
NFS_LAYOUT_DRAIN in the following scenario

1. cpu a: waiter test NFS_LAYOUT_DRAIN (1) and plh_outstanding (1)
2. cpu b: atomic_dec_and_test() -&gt; clear bit -&gt; wake up
3. cpu c: sets NFS_LAYOUT_DRAIN again
4. cpu a: calls wait_on_bit() sleeps forever.

To expand on this we have say 2 outstanding pnfs write IO that get
ESTALE which causes both to call pnfs_destroy_layout() and set the
NFS_LAYOUT_DRAIN bit but the 1st one doesn't call the
pnfs_put_layout_hdr() yet (as that would prevent the 2nd ESTALE write
from trying to call pnfs_destroy_layout()). If the 1st ESTALE write
is the one that initially sets the NFS_LAYOUT_DRAIN so that new IO
on this file initiates new LAYOUTGET. Another new write would find
NFS_LAYOUT_DRAIN set and phl_outstanding&gt;0 (step 1) and would
wait_on_bit(). LAYOUTGET completes doing step 2. Now, the 2nd of
ESTALE writes is calling pnfs_destory_layout() and set the
NFS_LAYOUT_DRAIN bit (step 3). Finally, the waiting write wakes up
to check the bit and goes back to sleep.

The problem revolves around the fact that if NFS_LAYOUT_INVALID_STID
was already set, it should not do the work of
pnfs_mark_layout_stateid_invalid(), thus NFS_LAYOUT_DRAIN will not
be set more than once for an invalid layout.

Suggested-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Fixes: 880265c77ac4 ("pNFS: Avoid a live lock condition in pnfs_update_layout()")
Signed-off-by: Olga Kornievskaia &lt;okorniev@redhat.com&gt;
Signed-off-by: Anna Schumaker &lt;anna.schumaker@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFS/localio: remove -EAGAIN handling in nfs_local_doio()</title>
<updated>2026-02-26T22:59:26+00:00</updated>
<author>
<name>Mike Snitzer</name>
<email>snitzer@kernel.org</email>
</author>
<published>2026-01-07T16:08:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=055cd68b8ebbd42aa425a594ccddd55e4c3d61d5'/>
<id>urn:sha1:055cd68b8ebbd42aa425a594ccddd55e4c3d61d5</id>
<content type='text'>
[ Upstream commit e72a73957613653f50375db1f3a3fbb907a9c40b ]

Handling -EAGAIN in nfs_local_doio() was introduced with commit
0978e5b85fc08 (nfs_do_local_{read,write} were made to have negative
checks for correspoding iter method) but commit e43e9a3a3d66
since eliminated the possibility for this -EAGAIN early return.

So remove nfs_local_doio()'s -EAGAIN handling that calls
nfs_localio_disable_client() -- while it should never happen from
nfs_do_local_{read,write} this particular -EAGAIN handling is now
"dead" and so it has become a liability.

Fixes: e43e9a3a3d66 ("nfs/localio: refactor iocb initialization")
Signed-off-by: Mike Snitzer &lt;snitzer@kernel.org&gt;
Signed-off-by: Anna Schumaker &lt;anna.schumaker@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFS/localio: use GFP_NOIO and non-memreclaim workqueue in nfs_local_commit</title>
<updated>2026-02-26T22:59:26+00:00</updated>
<author>
<name>Mike Snitzer</name>
<email>snitzer@hammerspace.com</email>
</author>
<published>2026-01-07T16:08:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1d6933f32b29710b97592c44563fe7e37434995b'/>
<id>urn:sha1:1d6933f32b29710b97592c44563fe7e37434995b</id>
<content type='text'>
[ Upstream commit 9bb0060f7860aa4561c5b21163dd45ceb66946a9 ]

nfslocaliod_workqueue is a non-memreclaim workqueue (it isn't
initialized with WQ_MEM_RECLAIM), see commit b9f5dd57f4a5
("nfs/localio: use dedicated workqueues for filesystem read and
write").

Use nfslocaliod_workqueue for LOCALIO's SYNC work.

Also, set PF_LOCAL_THROTTLE | PF_MEMALLOC_NOIO in
nfs_local_fsync_work.

Fixes: b9f5dd57f4a5 ("nfs/localio: use dedicated workqueues for filesystem read and write")
Signed-off-by: Mike Snitzer &lt;snitzer@hammerspace.com&gt;
Signed-off-by: Anna Schumaker &lt;anna.schumaker@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFS/localio: prevent direct reclaim recursion into NFS via nfs_writepages</title>
<updated>2026-02-26T22:59:26+00:00</updated>
<author>
<name>Mike Snitzer</name>
<email>snitzer@hammerspace.com</email>
</author>
<published>2026-01-07T16:08:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ae26a4cf2baf0a44c538dc093504d1994b02dade'/>
<id>urn:sha1:ae26a4cf2baf0a44c538dc093504d1994b02dade</id>
<content type='text'>
[ Upstream commit 67435d2d8a33a75f9647724952cb1b18279d2e95 ]

LOCALIO is an NFS loopback mount optimization that avoids using the
network for READ, WRITE and COMMIT if the NFS client and server are
determined to be on the same system. But because LOCALIO is still
fundamentally "just NFS loopback mount" it is susceptible to recursion
deadlock via direct reclaim, e.g.: NFS LOCALIO down to XFS and then
back into NFS via nfs_writepages.

Fix LOCALIO's potential for direct reclaim deadlock by ensuring that
all its page cache allocations are done from GFP_NOFS context.

Thanks to Ben Coddington for pointing out commit ad22c7a043c2 ("xfs:
prevent stack overflows from page cache allocation").

Reported-by: John Cagle &lt;john.cagle@hammerspace.com&gt;
Tested-by: Allen Lu &lt;allen.lu@hammerspace.com&gt;
Suggested-by: Benjamin Coddington &lt;bcodding@hammerspace.com&gt;
Fixes: 70ba381e1a43 ("nfs: add LOCALIO support")
Signed-off-by: Mike Snitzer &lt;snitzer@hammerspace.com&gt;
Signed-off-by: Anna Schumaker &lt;anna.schumaker@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFS/localio: Handle short writes by retrying</title>
<updated>2026-02-26T22:59:26+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@hammerspace.com</email>
</author>
<published>2026-01-03T17:14:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c627769730e98c4dbff0d5f5d194f467d79df326'/>
<id>urn:sha1:c627769730e98c4dbff0d5f5d194f467d79df326</id>
<content type='text'>
[ Upstream commit 615762059d284b863f9163b53679d95b3dcdd495 ]

The current code for handling short writes in localio just truncates the
I/O and then sets an error. While that is close to how the ordinary NFS
code behaves, it does mean there is a chance the data that got written
is lost because it isn't persisted.
To fix this, change localio so that the upper layers can direct the
behaviour to persist any unstable data by rewriting it, and then
continuing writing until an ENOSPC is hit.

Fixes: 70ba381e1a43 ("nfs: add LOCALIO support")
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Reviewed-by: Mike Snitzer &lt;snitzer@kernel.org&gt;
Signed-off-by: Anna Schumaker &lt;anna.schumaker@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFS: Fix size read races in truncate, fallocate and copy offload</title>
<updated>2026-01-23T10:21:20+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@hammerspace.com</email>
</author>
<published>2026-01-10T23:53:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=94413a84067c31a787c8973c9b150088601ff4e7'/>
<id>urn:sha1:94413a84067c31a787c8973c9b150088601ff4e7</id>
<content type='text'>
[ Upstream commit d5811e6297f3fd9020ac31f51fc317dfdb260cb0 ]

If the pre-operation file size is read before locking the inode and
quiescing O_DIRECT writes, then nfs_truncate_last_folio() might end up
overwriting valid file data.

Fixes: b1817b18ff20 ("NFS: Protect against 'eof page pollution'")
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFS/localio: Deal with page bases that are &gt; PAGE_SIZE</title>
<updated>2026-01-23T10:21:14+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@hammerspace.com</email>
</author>
<published>2026-01-02T23:55:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d6ea0b7394a443fb6ddd1a3619ccc2f0781a900c'/>
<id>urn:sha1:d6ea0b7394a443fb6ddd1a3619ccc2f0781a900c</id>
<content type='text'>
[ Upstream commit 60699ab7cbf0a4eb19929cce243002b39c67917d ]

When resending requests, etc, the page base can quickly grow larger than
the page size.

Fixes: 091bdcfcece0 ("nfs/localio: refactor iocb and iov_iter_bvec initialization")
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Reviewed-by: Mike Snitzer &lt;snitzer@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pnfs/blocklayout: Fix memory leak in bl_parse_scsi()</title>
<updated>2026-01-23T10:21:14+00:00</updated>
<author>
<name>Zilin Guan</name>
<email>zilin@seu.edu.cn</email>
</author>
<published>2025-12-25T08:45:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=51926204465e7d2ce71c396e0403aed58140a292'/>
<id>urn:sha1:51926204465e7d2ce71c396e0403aed58140a292</id>
<content type='text'>
[ Upstream commit 5a74af51c3a6f4cd22c128b0c1c019f68fa90011 ]

In bl_parse_scsi(), if the block device length is zero, the function
returns immediately without releasing the file reference obtained via
bl_open_path(), leading to a memory leak.

Fix this by jumping to the out_blkdev_put label to ensure the file
reference is properly released.

Fixes: d76c769c8db4c ("pnfs/blocklayout: Don't add zero-length pnfs_block_dev")
Signed-off-by: Zilin Guan &lt;zilin@seu.edu.cn&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
