On Tue, Mar 15, 2022 at 05:41:30AM -0700, trix at redhat.com
wrote:> From: Tom Rix <trix at redhat.com>
>
> Clang static analysis reports this issue
> ifcvf_main.c:49:4: warning: Called function
> pointer is null (null dereference)
> vf->vring->cb.callback(vring->cb.private);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> The check
> vring = &vf->vring[i];
> if (vring->cb.callback)
>
> Does not match the use. Change dereference so they match.
>
> Fixes: 79333575b8bd ("vDPA/ifcvf: implement shared IRQ feature")
> Signed-off-by: Tom Rix <trix at redhat.com>
> ---
> drivers/vdpa/ifcvf/ifcvf_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c
b/drivers/vdpa/ifcvf/ifcvf_main.c
> index 3b48e717e89f7..4366320fb68d3 100644
> --- a/drivers/vdpa/ifcvf/ifcvf_main.c
> +++ b/drivers/vdpa/ifcvf/ifcvf_main.c
> @@ -46,7 +46,7 @@ static irqreturn_t ifcvf_vqs_reused_intr_handler(int irq,
void *arg)
> for (i = 0; i < vf->nr_vring; i++) {
> vring = &vf->vring[i];
> if (vring->cb.callback)
> - vf->vring->cb.callback(vring->cb.private);
> + vring->cb.callback(vring->cb.private);
> }
>
> return IRQ_HANDLED;
Oh, absolutely. In fact vf->vring->cb.callback is just
vf->vring[0].cb.callback so it's wrong for any ring except 0. Does not
make sense.
So how did it work in testing then? No idea.
Zhu Lingshan, care to comment?
> --
> 2.26.3