[PATCH v5 15/36] srcu: Support Clang's context analysis
Bart Van Assche
bvanassche at acm.org
Mon Jan 26 18:54:56 UTC 2026
On 1/26/26 10:35 AM, Marco Elver wrote:
> That being said, I don't think it's wrong to write e.g.:
>
> spin_lock(&updater_lock);
> __acquire_shared(ssp);
> ...
> // writes happen through rcu_assign_pointer()
> // reads can happen through srcu_dereference_check()
> ...
> __release_shared(ssp);
> spin_unlock(&updater_lock);
>
> , given holding the updater lock implies reader access.
>
> And given the analysis is opt-in (CONTEXT_ANALYSIS := y), I think
> it's a manageable problem.
I'd like to make context-analysis mandatory for the entire kernel tree.
> If you have a different idea how we can solve this, please let us know.
>
> One final note, usage of srcu_dereference_check() is rare enough:
>
> arch/x86/kvm/hyperv.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
> arch/x86/kvm/x86.c: kvm_free_msr_filter(srcu_dereference_check(kvm->arch.msr_filter, &kvm->srcu, 1));
> arch/x86/kvm/x86.c: kfree(srcu_dereference_check(kvm->arch.pmu_event_filter, &kvm->srcu, 1));
> drivers/gpio/gpiolib.c: label = srcu_dereference_check(desc->label, &desc->gdev->desc_srcu,
> drivers/hv/mshv_irq.c: girq_tbl = srcu_dereference_check(partition->pt_girq_tbl,
> drivers/hwtracing/stm/core.c: link = srcu_dereference_check(src->link, &stm_source_srcu, 1);
> drivers/infiniband/hw/hfi1/user_sdma.c: pq = srcu_dereference_check(fd->pq, &fd->pq_srcu,
> fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
> fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
> fs/quota/dquot.c: put[cnt] = srcu_dereference_check(dquots[cnt], &dquot_srcu,
> fs/quota/dquot.c: transfer_from[cnt] = srcu_dereference_check(dquots[cnt],
> include/linux/kvm_host.h: return srcu_dereference_check(kvm->memslots[as_id], &kvm->srcu,
> virt/kvm/irqchip.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
>
> , that I think it's easy enough to annotate these places with the above
> suggestions in case you're trying out global enablement.
Has it ever been considered to add support in the clang compiler for a
variant of __must_hold() that expresses that one of two capabilities
must be held by the caller? I think that would remove the need to
annotate SRCU update-side code with __acquire_shared(ssp) and
__release_shared(ssp).
Thanks,
Bart.
More information about the Linux-security-module-archive
mailing list