summaryrefslogtreecommitdiff
path: root/scripts/lib/kdoc/kdoc_re.py
diff options
context:
space:
mode:
authorChristian Brauner <brauner@kernel.org>2025-10-31 13:11:44 +0100
committerChristian Brauner <brauner@kernel.org>2025-10-31 13:11:44 +0100
commita77a59592febd4179efa6b59f2ef5bdfe9a5b895 (patch)
tree37851ee99a28edff992bccd57be9670b52727a85 /scripts/lib/kdoc/kdoc_re.py
parent3a8660878839faadb4f1a6dd72c3179c1df56787 (diff)
parent60a70e61430b2d568bc5e96f629c5855ee159ace (diff)
Merge patch series "Add and use folio_next_pos()"
Matthew Wilcox (Oracle) <willy@infradead.org> says: It's relatively common in filesystems to want to know the end of the current folio we're looking at. So common in fact that btrfs has its own helper for that. Lift that helper to filemap and use it everywhere that I've noticed it could be used. This actually fixes a long-standing bug in ocfs2 on 32-bit systems with files larger than 2GiB. Presumably this is not a common configuration, but I've marked it for backport anyway. The other filesystems are all fine; none of them have a bug, they're just mildly inefficient. I think this should all go in via Christian's tree, ideally with acks from the various fs maintainers (cc'd on their individual patches). * patches from https://patch.msgid.link/20251024170822.1427218-1-willy@infradead.org: mm: Use folio_next_pos() xfs: Use folio_next_pos() netfs: Use folio_next_pos() iomap: Use folio_next_pos() gfs2: Use folio_next_pos() f2fs: Use folio_next_pos() ext4: Use folio_next_pos() buffer: Use folio_next_pos() btrfs: Use folio_next_pos() filemap: Add folio_next_pos() Link: https://patch.msgid.link/20251024170822.1427218-1-willy@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
Diffstat (limited to 'scripts/lib/kdoc/kdoc_re.py')
0 files changed, 0 insertions, 0 deletions