Re: [PATCH v5 15/36] srcu: Support Clang's context analysis

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.