<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/next/linux-next.git/fs/ceph, branch master</title>
<subtitle>The linux-next integration testing tree</subtitle>
<id>https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=master</id>
<link rel='self' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/'/>
<updated>2026-09-10T11:38:10+00:00</updated>
<entry>
<title>Merge branch 'vfs.all' of https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git</title>
<updated>2026-09-10T11:38:10+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2026-09-10T11:38:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f58622472a1e1b4751ed23508055e3d21a208e30'/>
<id>urn:sha1:f58622472a1e1b4751ed23508055e3d21a208e30</id>
<content type='text'>
# Conflicts:
#	tools/testing/selftests/Makefile
</content>
</entry>
<entry>
<title>Merge tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux</title>
<updated>2026-09-06T03:45:18+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2026-09-06T03:45:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=1fc5a74b108fc90951890ec513ac81869f5eaff1'/>
<id>urn:sha1:1fc5a74b108fc90951890ec513ac81869f5eaff1</id>
<content type='text'>
Pull kmalloc_obj conversions from Kees Cook:
 "Another run of the Coccinelle script for converting kmalloc()
  family of allocations to kmalloc_obj() via the existing rules
  in scripts/coccinelle/api/kmalloc_objs.cocci"

* tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  treewide: refresh kmalloc_obj() conversions
  drm/amd/display: Fix harmless type mismatch in allocation
</content>
</entry>
<entry>
<title>treewide: refresh kmalloc_obj() conversions</title>
<updated>2026-09-05T04:37:00+00:00</updated>
<author>
<name>Kees Cook</name>
<email>kees+treewide@kernel.org</email>
</author>
<published>2026-09-02T22:31:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=3a2c4d55e32ad65efebdb6de44eef3bfa08bb49d'/>
<id>urn:sha1:3a2c4d55e32ad65efebdb6de44eef3bfa08bb49d</id>
<content type='text'>
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci

This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.

Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.

Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook &lt;kees+treewide@kernel.org&gt;
</content>
</entry>
<entry>
<title>ceph: apply nearfull_sync option on remount</title>
<updated>2026-09-02T10:23:05+00:00</updated>
<author>
<name>Alex Markuze</name>
<email>amarkuze@redhat.com</email>
</author>
<published>2026-08-27T15:16:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=dc173b37415e8f738fc4de477490056b479ddc9f'/>
<id>urn:sha1:dc173b37415e8f738fc4de477490056b479ddc9f</id>
<content type='text'>
ceph_parse_mount_param() stores nearfull_sync / nonearfull_sync on the
temporary fs_context options, but ceph_reconfigure_fc() never copied
CEPH_MOUNT_OPT_NEARFULL_SYNC onto the live mount. Remount therefore
succeeded while writes and /proc/mounts kept the original-mount flag.

Apply the flag the same way as ASYNC_DIROPS and SPARSEREAD so remount
can enable or disable NEARFULL IOCB_DSYNC promotion.

Fixes: c7a12c20bfba ("ceph: make nearfull sync writes opt-in")
Signed-off-by: Alex Markuze &lt;amarkuze@redhat.com&gt;
Reviewed-by: Xiubo Li &lt;xiubo.li@clyso.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
</content>
</entry>
<entry>
<title>ceph: lock mutex in ceph_mds_check_access()</title>
<updated>2026-09-02T10:22:03+00:00</updated>
<author>
<name>Max Kellermann</name>
<email>max.kellermann@ionos.com</email>
</author>
<published>2026-08-24T16:47:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a61c6ae1dae2611082b831b4aaa780878099c012'/>
<id>urn:sha1:a61c6ae1dae2611082b831b4aaa780878099c012</id>
<content type='text'>
MDS session OPEN handling replaces mdsc-&gt;s_cap_auths under
mdsc-&gt;mutex, freeing the previous array and its strings.

ceph_mds_check_access() traverses this array without holding the
mutex.  A concurrent session reopen can therefore free the array while
it is being inspected, resulting in a use-after-free like this:

  Unable to handle kernel paging request at virtual address 003aaad64b2c8bb9
  [...]
  Internal error: Oops: 0000000096000004 [#1]  SMP
  Modules linked in:
  CPU: 56 UID: 2953037534 PID: 1253231 Comm: php-cgi8.4 Not tainted 6.18.45-i2-ampere #1146 NONE
  [..]
  pc : ceph_mds_check_access+0xd4/0x550
  lr : ceph_mds_check_access+0xc8/0x550
  [...]
  Call trace:
   ceph_mds_check_access+0xd4/0x550 (P)
   ceph_atomic_open+0x138/0xbe8
   path_openat+0xa24/0xfa8
   do_filp_open+0x94/0x158
   do_sys_openat2+0x88/0xf8

Cc: stable@vger.kernel.org
Fixes: 596afb0b8933 ("ceph: add ceph_mds_check_access() helper")
Signed-off-by: Max Kellermann &lt;max.kellermann@ionos.com&gt;
Reviewed-by: Alex Markuze &lt;amarkuze@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
</content>
</entry>
<entry>
<title>vfs: move O_IS_MKDIR check from lookup_open() into individual filesystems</title>
<updated>2026-08-31T08:32:26+00:00</updated>
<author>
<name>Jori Koolstra</name>
<email>jkoolstra@xs4all.nl</email>
</author>
<published>2026-08-23T16:07:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=65c4144bb147aa3f61fb0ad6098514e55b1eace8'/>
<id>urn:sha1:65c4144bb147aa3f61fb0ad6098514e55b1eace8</id>
<content type='text'>
Individual filesystems that implement -&gt;atomic_open() need to get the
chance to implement O_CREAT|O_DIRECTORY or not, rather than decide
this at the VFS level in lookup_open().

Signed-off-by: Jori Koolstra &lt;jkoolstra@xs4all.nl&gt;
Link: https://patch.msgid.link/20260823160706.358293-8-jkoolstra@xs4all.nl
Signed-off-by: Christian Brauner (Amutable) &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'ceph-for-7.3-rc1' of https://github.com/ceph/ceph-client</title>
<updated>2026-08-28T18:51:05+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2026-08-28T18:51:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=548e7bcd0c5460ddcbca9600cea603ebeebf4da7'/>
<id>urn:sha1:548e7bcd0c5460ddcbca9600cea603ebeebf4da7</id>
<content type='text'>
Pull ceph updates from Ilya Dryomov:
 "A wide variety of mostly CephFS fixes and cleanups, split between
  changes that address edge cases (Sam, Xiubo, Matthew), efficiency
  improvements (Max) and AI-assisted hardening (Michael, Jeremy).

  One thing that stands out is Alex's change to how CephFS behaves in
  NEARFULL scenarios: the long-standing "make all writes synchronous"
  behavior has become opt-in. It was always somewhat controversial and
  doesn't make much sense for modern deployments; the new default is to
  continue normal operation (i.e. buffer writes as MDS allows, etc). The
  behavior in case the cluster reaches any FULL state remains the same
  as before"

* tag 'ceph-for-7.3-rc1' of https://github.com/ceph/ceph-client: (32 commits)
  ceph: force a cap message when a deferred revoke can't be acked immediately
  libceph: reject buckets with mismatched CRUSH ids
  ceph: reject export_targets ranks &gt;= CEPH_MAX_MDS in mdsmap decode
  ceph: fix leaked inode reference on writeback abort at umount
  libceph: remove ceph_put_page_vector()
  libceph: validate banner payload length
  ceph: make nearfull sync writes opt-in
  ceph: do not repeat ceph_trim_dentries() if no progress possible
  ceph: drop mdsc-&gt;mutex before decoding the MDS reply
  ceph: fix UAF in check_new_map() on session freed during unlock
  ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock
  ceph: pass inode pointer around instead of reloading it
  ceph: mark cap remove with RB_CLEAR_NODE() instead of setting ci=NULL
  ceph: add helper function ceph_cap_is_removed()
  ceph: make __ceph_remove_cap() static
  ceph: cap delegated inode count in ceph_parse_deleg_inos()
  ceph: bound num_export_targets array for mds info v2/v3
  ceph: bound MDSCapAuth path and fs_name decode in handle_session()
  ceph: bound xattr value length in __build_xattrs()
  ceph: bound copied dentry name length in NFS export get_name
  ...
</content>
</entry>
<entry>
<title>ceph: force a cap message when a deferred revoke can't be acked immediately</title>
<updated>2026-08-26T17:57:29+00:00</updated>
<author>
<name>Max Kellermann</name>
<email>max.kellermann@ionos.com</email>
</author>
<published>2026-08-18T18:40:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=8fdf946445732c2bcd685abc8bd0e509d2ebc158'/>
<id>urn:sha1:8fdf946445732c2bcd685abc8bd0e509d2ebc158</id>
<content type='text'>
When the MDS revokes capabilities, handle_cap_grant() normally
guarantees a response by setting `CHECK_CAPS_FLUSH_FORCE` (see
commit 31634d7597d8 ("ceph: force sending a cap update msg back to MDS
for revoke op")), so ceph_check_caps() sends a cap message even if the
client would otherwise decide it has nothing to do.  That guarantee is
skipped whenever the revoke has to be deferred (via revoke_wait):
revoking Fb while dirty data is still buffered (writeback is queued
first) or revoking Fc while pages are cached (async invalidation is
queued first).

In those cases, the ack is left to the deferred completion
(ceph_put_wrbuffer_cap_refs() after writeback, or the invalidate
worker after invalidation); both of which call ceph_check_caps(ci,0)
i.e.  without `CHECK_CAPS_FLUSH_FORCE`.  Nothing gets sent under one
of the following conditions:

- the inode is retaining caps because the file was used recently
  (file_wanted != 0; retain |= CEPH_CAP_ANY)

- the revoked cap is still used because the page was re-cached (e.g. a
  file being re-read)

- the MDS has meanwhile re-granted, so `issued==implemented` and the
  client sees nothing being revoked

The client then never emits the cap message which the MDS is waiting
for.  The MDS blocks on the revoke indefinitely and logs, for minutes
or hours:

  client.NNN isn't responding to mclientcaps(revoke), ino 0x... pending
  pAsxLsXsxFsxcrwb issued pAsxLsXsxFsxcrwb, sent 964.899182 seconds ago

The client-side state at that point shows the full cap set still
issued, nothing in the revoking/flushing sets.  Thus nothing gets
sent.

This patch fixes it by remembering that a forced response is expected.
When a revoke is deferred, set `CEPH_I_FLUSH_FORCE` on the inode.
ceph_check_caps() replays it as `CHECK_CAPS_FLUSH_FORCE`, so whichever
path re-checks the inode next (the writeback/invalidate completion,
the delayed worker, or any other caller) is guaranteed to send a cap
message to the MDS.  __prep_cap() clears the flag once a message is
actually built.

This is the deferred-path counterpart of the existing
`CHECK_CAPS_FLUSH_FORCE` handling; a normal (non-deferred) revoke
still forces the response inline as before.

Cc: stable@vger.kernel.org
Fixes: 31634d7597d8 ("ceph: force sending a cap update msg back to MDS for revoke op")
Fixes: 257e6172ab36 ("ceph: don't let check_caps skip sending responses for revoke msgs")
Signed-off-by: Max Kellermann &lt;max.kellermann@ionos.com&gt;
Reviewed-by: Alex Markuze &lt;amarkuze@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
</content>
</entry>
<entry>
<title>ceph: reject export_targets ranks &gt;= CEPH_MAX_MDS in mdsmap decode</title>
<updated>2026-08-26T17:57:29+00:00</updated>
<author>
<name>Jérémy Jean</name>
<email>Jeremy.Jean@oss.cyber.gouv.fr</email>
</author>
<published>2026-08-13T12:00:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=aedc9053d909508a5f56c3f49f885fc030df4730'/>
<id>urn:sha1:aedc9053d909508a5f56c3f49f885fc030df4730</id>
<content type='text'>
MDSMap export_targets entries are monitor controlled. check_new_map()
uses each entry as a bit number in a fixed stack bitmap, so a rank
outside the protocol namespace can make set_bit() write past the end of
the array.

Reject ranks outside CEPH_MAX_MDS while decoding the map. Do not
validate against possible_max_rank here because maps may legitimately
reference ranks beyond a temporarily reduced max_mds.

Cc: stable@vger.kernel.org
Fixes: d517b3983dd3 ("ceph: reconnect to the export targets on new mdsmaps")
Signed-off-by: Jérémy Jean &lt;Jeremy.Jean@oss.cyber.gouv.fr&gt;
Reviewed-by: Alex Markuze &lt;amarkuze@redhat.com&gt;
Signed-off-by: Alex Markuze &lt;amarkuze@redhat.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
</content>
</entry>
<entry>
<title>ceph: fix leaked inode reference on writeback abort at umount</title>
<updated>2026-08-26T17:57:28+00:00</updated>
<author>
<name>Matthew Brown</name>
<email>matthew@bargrove.com</email>
</author>
<published>2026-08-12T17:13:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c25aee9c630fb86f98d79eccb75765067079b972'/>
<id>urn:sha1:c25aee9c630fb86f98d79eccb75765067079b972</id>
<content type='text'>
ceph_dirty_folio() takes a wrbuffer claim on each newly dirtied folio: it
bumps i_wrbuffer_ref (taking an ihold() on the 0-&gt;1 transition) and
attaches the snap_context to folio-&gt;private.  That claim is released only
by ceph_put_wrbuffer_cap_refs(), which for a submitted write runs from
writepages_finish().

In ceph_submit_write(), if ceph_inc_osd_stopping_blocker() fails -- which
happens during umount -- the request is aborted before submission: the
already-collected folios are only redirtied and unlocked, so
writepages_finish() never runs and the claim is leaked.
redirty_page_for_writepage() -&gt; folio_redirty_for_writepage() -&gt;
filemap_dirty_folio() sets PG_dirty directly and does not go through
-&gt;dirty_folio, so ceph_dirty_folio() is not re-entered to rebalance it.
Because every subsequent writeback also fails the osd_stopping_blocker,
i_wrbuffer_ref never returns to 0, the ihold() is never dropped, and the
inode cannot be evicted:

  VFS: Busy inodes after unmount of ceph
  kernel BUG at fs/super.c:650!

Release the orphaned claim in the abort path before redirtying, via
ceph_undo_wrbuffer_claim(): detach the snap_context, drop the wrbuffer
reference (letting i_wrbuffer_ref reach 0 and iput() the inode), and drop
the snap_context reference -- i.e. do what writepages_finish() would have
done for these never-submitted folios.

Only the locked_pages entries are undone; folios still in the fbatch were
never dirty-cleared by this call (folio_clear_dirty_for_io() is the
ownership-transfer point, and a successful move NULLs the fbatch slot), so
they hold no claim this call owns.

Cc: stable@vger.kernel.org
Fixes: fd7449d937e7 ("ceph: fix generic/421 test failure")
Signed-off-by: Matthew Brown &lt;matthew@bargrove.com&gt;
Reviewed-by: Xiubo Li &lt;xiubo.li@clyso.com&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
</content>
</entry>
</feed>
