From: Paulo Alcantara <pc@manguebit.org>
To: linux-cifs@vger.kernel.org, netfs@lists.linux.dev,
David Howells <dhowells@redhat.com>
Cc: Namjae Jeon <linkinjeon@kernel.org>,
Ronnie Sahlberg <ronniesahlberg@gmail.com>,
Shyam Prasad N <sprasad@microsoft.com>,
Tom Talpey <tom@talpey.com>, Bharath SM <bharathsm@microsoft.com>,
Christian Brauner <brauner@kernel.org>,
stable@vger.kernel.org
Subject: [PATCH v7 04/19] netfs: don't hang a read whose retry is abandoned
Date: Fri, 6 Nov 2026 20:18:12 -0300 [thread overview]
Message-ID: <20261106231827.2604956-5-pc@manguebit.org> (raw)
In-Reply-To: <20261106231827.2604956-1-pc@manguebit.org>
When ->prepare_read() fails while retrying a read, or a subrequest can't
be allocated, netfs_retry_read_subrequests() marks the remaining
subrequests failed without reissuing them. If none was reissued in that
pass, nothing is in progress any more to wake the collector, which
returned after the retry, so an offloaded read (readahead, async direct
I/O) never completes and its folios stay locked.
Wake the collector after abandoning, so it collects the failed
subrequests and completes the request.
Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item")
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
Cc: stable@vger.kernel.org
---
fs/netfs/read_retry.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/netfs/read_retry.c b/fs/netfs/read_retry.c
index 8a722995fa9d..bfaaebea12df 100644
--- a/fs/netfs/read_retry.c
+++ b/fs/netfs/read_retry.c
@@ -269,6 +269,7 @@ static void netfs_retry_read_subrequests(struct netfs_io_request *rreq)
__set_bit(NETFS_SREQ_FAILED, &subreq->flags);
__clear_bit(NETFS_SREQ_NEED_RETRY, &subreq->flags);
}
+ netfs_wake_collector(rreq);
}
/*
--
2.56.0
next prev parent reply other threads:[~2026-11-06 23:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 23:18 [PATCH v7 00/19] smb: client: fix data loss in writeback Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 01/19] smb: client: don't write back through O_DIRECT handles Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 02/19] netfs: preserve prepare_write errno on reissue Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 03/19] netfs: keep the prepare_read errno when abandoning read retries Paulo Alcantara
2026-11-06 23:18 ` Paulo Alcantara [this message]
2026-11-06 23:18 ` [PATCH v7 05/19] smb: client: let umount -f abort retried reads and writes Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 06/19] smb: client: don't give up writeback on the first replayable error Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 07/19] smb: client: don't retry failed writes forever regardless of mount options Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 08/19] smb: client: don't spend read retries on reads cut short by a reconnect Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 09/19] smb: client: don't block dying tasks waiting for writeback on close Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 10/19] smb: client: issue writes from a worker if the task is dying Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 11/19] smb: client: don't fail writeback preparation " Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 12/19] smb: client: retry writeback on interrupts and allocation failures Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 13/19] smb: client: don't block dying tasks waiting for writeback on fsync Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 14/19] smb: client: retry writes that couldn't be issued due to a reconnect Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 15/19] smb: client: retry writeback after losing the connection, share or handle Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 16/19] smb: client: let umount -f stop waiting for reconnects on hard mounts Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 17/19] smb: client: don't replay handle reopens inside SMB2_open() Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 18/19] smb: client: fail writeback sends and reopens fast when the server is gone Paulo Alcantara
2026-11-06 23:18 ` [PATCH v7 19/19] smb: client: stop reconnecting and replaying during a forced unmount Paulo Alcantara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261106231827.2604956-5-pc@manguebit.org \
--to=pc@manguebit.org \
--cc=bharathsm@microsoft.com \
--cc=brauner@kernel.org \
--cc=dhowells@redhat.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=netfs@lists.linux.dev \
--cc=ronniesahlberg@gmail.com \
--cc=sprasad@microsoft.com \
--cc=stable@vger.kernel.org \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox