qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: How can I find problematic uses of error_report() with vrc?
Date: Mon, 8 May 2023 17:11:23 +0200	[thread overview]
Message-ID: <daf7118f-23ee-c883-d033-17c8e10cdc61@redhat.com> (raw)
In-Reply-To: <70100e22-6d7d-bb84-b2ed-e64d7929d2c5@redhat.com>

One fixlet:

On 5/8/23 12:41, Paolo Bonzini wrote:
> Let's just cut out function  pointers for simplicity:
> 
> (vrc) paths --limit 1 qemu_ram_resize [!ErrorPP,function_pointer]* 
> error_report
> <no output>

This should have been

   paths --limit 1 qemu_ram_resize [!ErrorPP,!function_pointer]* error_report

but the output is indeed empty; it was just a matter of cutting-and-
pasting from the wrong line.

It could also be written using DeMorgan's law as

   paths --limit 1 qemu_ram_resize [![ErrorPP|function_pointer]]* error_report

where the outer brackets are not necessary but improve readability.

Paolo

> Okay, so this one was a false positive as well.
> 
> So you can see the good and the bad here.  The tool is powerful and 
> finds what you asked.  The problem is that there's _a lot_ of hay in 
> which you have to find the needle.  For coroutines it works bettr 
> because we have already cleaned it up, you can get there but it takes 
> some sweat.
> 
> [here]
> 
> Let's try a more precise (but also more restrictive) query that only has 
> a single function that does not take Error** but calls error_report:
> 
> (vrc) paths [ErrorPP] [ErrorPP]* [!ErrorPP] error_report
> error_report <- qemu_open_old <- qmp_chardev_open_file_source
> error_report <- runstate_set <- qemu_system_wakeup_request
> error_report <- machine_consume_memdev <- machine_run_board_init
> error_report <- numa_complete_configuration <- machine_run_board_init
> error_report <- egl_rendernode_init <- egl_init
> error_report <- parse_numa_node <- set_numa_options
> 
> I checked parse_numa_node and numa_complete_configuration, and they're 
> genuine issues.
> 
> Let's add a couple labels by hand to see if it finds your example:
> 
> (vrc) label ErrorPP qmp_migrate rdma_start_outgoing_migration 
> qemu_rdma_source_init
> (vrc) paths qmp_migrate [ErrorPP]* [!ErrorPP] error_report
> error_report <- migrate_fd_connect <- rdma_start_outgoing_migration <- 
> qmp_migrate
> error_report <- qemu_rdma_cleanup <- rdma_start_outgoing_migration <- 
> qmp_migrate
> error_report <- qemu_rdma_resolve_host <- qemu_rdma_source_init <- 
> rdma_start_outgoing_migration <- qmp_migrate
> error_report <- qemu_rdma_alloc_pd_cq <- qemu_rdma_source_init <- 
> rdma_start_outgoing_migration <- qmp_migrate
> error_report <- qemu_rdma_cleanup <- qemu_rdma_source_init <- 
> rdma_start_outgoing_migration <- qmp_migrate
> error_report <- qemu_rdma_reg_control <- qemu_rdma_source_init <- 
> rdma_start_outgoing_migration <- qmp_migrate
> error_report <- qemu_rdma_connect <- rdma_start_outgoing_migration <- 
> qmp_migrate
> 
> Mission accomplished. :)
> 
> Paolo
> 
>> Here's my find-error-fns.cocci:
>>
>> @r@
>> identifier fn, errp;
>> position p;
>> @@
>>   fn@p(..., Error **errp, ...)
>>   {
>>       ...
>>   }
>> @script:python@
>> fn << r.fn;
>> p << r.p;
>> @@
>> print(f'{p[0].file}:{p[0].line}:{p[0].column}:{fn}')
>>



      reply	other threads:[~2023-05-08 15:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-08  8:32 How can I find problematic uses of error_report() with vrc? Markus Armbruster
2023-05-08 10:41 ` Paolo Bonzini
2023-05-08 15:11   ` Paolo Bonzini [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=daf7118f-23ee-c883-d033-17c8e10cdc61@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=armbru@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).