RE: [PATCH 1/1] libceph: use RCU to protect monmap in ceph_compare_options()

[Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>]

On Fri, 2026-07-10 at 10:16 +0800, Yong Wang wrote:
> 
> 在 2026/7/9 6:43, Viacheslav Dubeyko 写道:
> > On Wed, 2026-07-08 at 11:03 +0800, Ren Wei wrote:
> > > From: Yong Wang <edragain@163.com>
> > > 
> > > ceph_compare_options() checks whether a new mount shares any monitor
> > > address with an existing client by walking client->monc.monmap via
> > > ceph_monmap_contains().  That comparison can run under sb_lock or
> > > rbd_client_list_lock, so it cannot take monc->mutex.
> > > 
> > > Meanwhile, monmap update handling replaces monc->monmap under
> > > monc->mutex and frees the old map immediately.  A concurrent shared-
> > > mount comparison can therefore dereference a freed monmap and walk
> > > stale mon_inst[] entries, triggering a use-after-free.
> > > 
> > > Protect the compare path with RCU and publish/free monitor maps with
> > > rcu_assign_pointer() and kfree_rcu().  Annotate monc->monmap as an
> > > RCU pointer and use rcu_dereference_protected() in mutex-protected
> > > paths to keep the accesses consistent with the new pointer contract.
> > > 
> > > This keeps the existing non-blocking comparison semantics while
> > > ensuring that replaced monmaps remain alive until readers are done.
> > 
> > The approach makes sense to me. However, I have some concern. If the replaced
> > monmap(s) could be in use with newly allocated one(s), then are we safe here?
> 
> The new monmap is fully allocated and initialized before publication, then
> installed with rcu_assign_pointer() under monc->mutex. Readers only dereference
> an RCU snapshot and treat the monmap as immutable, while the replaced monmap is
> freed with kfree_rcu(), which means the old map is not reclaimed immediately, 
> but is delayed until all readers that are still accessing it have exited the 
> read-side critical section.Readers only see either the old map or the new map.
> 
> So it is safe to use.
> 
> > Have you tried to run xfstests for the patch?
> 
> I ran the ceph xfstests in QEMU on the patched kernel, and all ceph-
> specific tests in the current tree passed: ceph/001-006.
> 
> 

The running only Ceph specific test-cases is not enough. The patch should
survive the auto group of xfstests.

Thanks,
Slava.