From: Rushil Patel <rushil.patel@gsacapital.com>
To: Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Rushil Patel <rushil.patel@gsacapital.com>
Subject: [RFC PATCH 0/1] mm/filemap: make writeback wait killable in __filemap_fdatawait_range()
Date: Wed, 25 Mar 2026 11:36:15 +0000 [thread overview]
Message-ID: <20260325113616.785496-1-rushil.patel@gsacapital.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3353 bytes --]
We run Slurm on compute nodes with NFS mounts (NFSv4.1, NetApp).
When a job is cancelled, processes with dirty NFS pages get stuck
in D-state inside folio_wait_bit_common() because
__filemap_fdatawait_range() uses folio_wait_writeback(), which is
TASK_UNINTERRUPTIBLE. If the filer is slow to respond these processes are
unkillable - we've found the only recovery in practice is rebooting
the node.
The patch switches to folio_wait_writeback_killable() so SIGKILL can
interrupt the wait. Writeback itself continues on the server, we just stop
waiting for the ack. All 6 callers of __filemap_fdatawait_range() detect
errors independently via errseq_t / filemap_check_errors(), so the early
return doesn't suppress error reporting.
The tricky part is a re-entry through do_exit(). Making the wait killable
alone isn't enough - we hit this in testing:
1. SIGKILL wakes the killable wait, signal is consumed by get_signal()
2. do_exit() -> exit_signals() sets PF_EXITING
3. do_exit() -> exit_files() -> nfs4_file_flush() -> nfs_wb_all()
re-enters __filemap_fdatawait_range()
4. wants_signal() checks PF_EXITING *before* the SIGKILL special case
(kernel/signal.c:951 vs 954), so it returns false
5. No signal can wake the second wait -> stuck in D-state again
The PF_EXITING check at the top of the function avoids re-entering the
wait entirely. This is the same pattern used in mm/oom_kill.c,
mm/memcontrol.c, block/blk-ioc.c, and io_uring/.
Reproduced with iptables DROP on port 2049, confirmed the killable-only
revision gets stuck on re-entry, and the PF_EXITING + killable revision
kills cleanly.
Sending as RFC because this touches the generic writeback sync path in
mm/filemap.c rather than being NFS-specific. NFS can't really fix this on
its own - it reaches __filemap_fdatawait_range() through
filemap_write_and_wait() and doesn't own the wait. But I wanted to get
guidance on whether this is the right place for the fix, or if you'd prefer
a different approach.
Best regards,
Rushil
Rushil Patel (1):
mm/filemap: make writeback wait killable in
__filemap_fdatawait_range()
mm/filemap.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
--
2.47.3
For details of how GSA uses your personal information, please see our Privacy Notice here: https://www.gsacapital.com/privacy-notice
This email and any files transmitted with it contain confidential and proprietary information and is solely for the use of the intended recipient.
If you are not the intended recipient please return the email to the sender and delete it from your computer and you must not use, disclose, distribute, copy, print or rely on this email or its contents.
This communication is for informational purposes only.
It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction.
Any comments or statements made herein do not necessarily reflect those of GSA Capital.
GSA Capital Partners LLP is authorised and regulated by the Financial Conduct Authority and is registered in England and Wales at Stratton House, 5 Stratton Street, London W1J 8LA, number OC309261.
GSA Capital Services Limited is registered in England and Wales at the same address, number 5320529.
[-- Attachment #2: Type: text/html, Size: 3751 bytes --]
next reply other threads:[~2026-03-25 11:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 11:36 Rushil Patel [this message]
2026-03-25 11:36 ` [RFC PATCH 1/1] mm/filemap: make writeback wait killable in __filemap_fdatawait_range() Rushil Patel
2026-03-25 19:15 ` [RFC PATCH 0/1] " Matthew Wilcox
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=20260325113616.785496-1-rushil.patel@gsacapital.com \
--to=rushil.patel@gsacapital.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/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