Re: [PATCH RFC 06/10] KVM: Add basic lock context annotations

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Using `container_of` inside a lock annotation attribute causes capability expression parsing errors and function pointer context mismatch.
--

commit 5dd3470925b8b06c17b9c9055b2f5ae6c47704d3
Author: Marco Elver <elver@google.com>

KVM: Add basic lock context annotations

This commit adds basic static lock context annotations across common KVM
sources. It deliberately omits dynamic multi-lock acquisition paths.

> diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
> --- a/virt/kvm/eventfd.c
> +++ b/virt/kvm/eventfd.c
[ ... ]
> @@ -300,6 +301,7 @@ struct kvm_irqfd_pt {
>  
>  static void kvm_irqfd_register(struct file *file, wait_queue_head_t *wqh,
>  			       poll_table *pt)
> +	__must_hold_shared(&container_of(pt, struct kvm_irqfd_pt, pt)->kvm->irq_srcu)
>  {

[Severity: Low]
Does using container_of() inside a lock annotation attribute cause capability 
expression parsing errors?

When context analysis is enabled (for instance, building with
CONFIG_WARN_CONTEXT_ANALYSIS), using statement expressions like container_of()
inside lock attributes can lead to Clang Thread Safety Analysis dropping the
attribute or reporting a function pointer type mismatch. 

Could this be annotated differently, or perhaps the lock status assumed
inside the function body instead, to avoid using the macro inside the
attribute?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910162343.4092060-1-elver@google.com?part=6