From: Christoph Hellwig <hch@lst.de>
To: Baoquan He <baoquan.he@linux.dev>
Cc: Christoph Hellwig <hch@lst.de>,
akpm@linux-foundation.org, chrisl@kernel.org,
usama.arif@linux.dev, kasong@tencent.com, nphamcs@gmail.com,
shikemeng@huaweicloud.com, youngjun.park@lge.com,
linux-mm@kvack.org
Subject: Re: [PATCH 7/8] mm/swap: remove SWP_FS_OPS
Date: Tue, 9 Jun 2026 10:45:11 +0200 [thread overview]
Message-ID: <20260609084511.GB11917@lst.de> (raw)
In-Reply-To: <aiJc5pPU_kvxs0a7@MiWiFi-R3L-srv>
On Fri, Jun 05, 2026 at 01:21:42PM +0800, Baoquan He wrote:
> + * SWAP_OPS_F_NOFS: swap operations that may recurse into the filesystem
> + * (e.g. NFS, CIFS). When set, callers (specifically reclaim) must operate
> + * under GFP_NOFS / !__GFP_FS to avoid deadlock. When clear (block-device
> + * swap), the swap I/O path does not touch the filesystem, so reclaim may
> + * safely enter the filesystem even with only __GFP_IO.
> + *
> + * In may_enter_fs() this appears as a double negative (!SWAP_OPS_F_NOFS)
> + * which reads as "not a nofs swap => may enter fs". This is intentional:
> + * it is bdev swap (the common case) that allows filesystem re-entry, while
> + * filesystem-based swap explicitly forbids it.
> + */
This is very verbose, but not incorrect. If everyone is fine with it,
I can add it to the next version.
Or if people think it is clearer. we can add a gfp constraint to the
ops?
next prev parent reply other threads:[~2026-06-09 8:45 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 11:34 better block swap batching and a different take on swap_ops v2 Christoph Hellwig
2026-06-01 11:34 ` [PATCH 1/8] shmem: provide a shmem_write_folio wrapper Christoph Hellwig
2026-06-04 9:43 ` Baoquan He
2026-06-05 17:07 ` Nhat Pham
2026-06-09 8:55 ` better shmem writeback interface for drm, was: " Christoph Hellwig
2026-06-01 11:34 ` [PATCH 2/8] mm: merge writeout into pageout Christoph Hellwig
2026-06-04 9:44 ` Baoquan He
2026-06-05 17:07 ` Nhat Pham
2026-06-09 8:49 ` 7.2 candidate? was: " Christoph Hellwig
2026-06-09 9:22 ` David Hildenbrand (Arm)
2026-06-01 11:34 ` [PATCH 3/8] mm/swap: introduce struct swap_io_ctx Christoph Hellwig
2026-06-04 10:58 ` Baoquan He
2026-06-05 17:41 ` Nhat Pham
2026-06-09 8:43 ` Christoph Hellwig
2026-06-01 11:34 ` [PATCH 4/8] mm/swap: also use struct swap_iocb for block I/O Christoph Hellwig
2026-06-04 10:59 ` Baoquan He
2026-06-04 11:37 ` Baoquan He
2026-06-01 11:34 ` [PATCH 5/8] mm/swap: remove count_swpout_vm_event Christoph Hellwig
2026-06-04 11:37 ` Baoquan He
2026-06-05 17:50 ` Nhat Pham
2026-06-01 11:34 ` [PATCH 6/8] mm/swap: use swap_ops to register swap device's methods Christoph Hellwig
2026-06-05 17:53 ` Nhat Pham
2026-06-01 11:34 ` [PATCH 7/8] mm/swap: remove SWP_FS_OPS Christoph Hellwig
2026-06-05 5:21 ` Baoquan He
2026-06-09 8:45 ` Christoph Hellwig [this message]
2026-06-05 17:58 ` Nhat Pham
2026-06-01 11:34 ` [PATCH 8/8] mm/vmstat: add NRSWP{IN,OUT} counters Christoph Hellwig
2026-06-05 7:16 ` Baoquan He
2026-06-09 8:46 ` Christoph Hellwig
2026-06-05 17:48 ` Nhat Pham
2026-06-01 13:29 ` better block swap batching and a different take on swap_ops v2 Baoquan He
2026-06-01 14:50 ` Christoph Hellwig
2026-06-01 15:17 ` Baoquan He
2026-06-01 15:25 ` Christoph Hellwig
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=20260609084511.GB11917@lst.de \
--to=hch@lst.de \
--cc=akpm@linux-foundation.org \
--cc=baoquan.he@linux.dev \
--cc=chrisl@kernel.org \
--cc=kasong@tencent.com \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=shikemeng@huaweicloud.com \
--cc=usama.arif@linux.dev \
--cc=youngjun.park@lge.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