All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: jianchunfu <jianchunfu@cmss.chinamobile.com>
Cc: clg@kaod.org, danielhb413@gmail.com, david@gibson.dropbear.id.au,
	groug@kaod.org, pbonzini@redhat.com, qemu-ppc@nongnu.org,
	kvm@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: [PATCH] target/ppc: Add error reporting when opening file fails
Date: Wed, 29 Jun 2022 07:56:32 +0200	[thread overview]
Message-ID: <87a69wrp0v.fsf@pond.sub.org> (raw)
In-Reply-To: <20220629031552.5407-1-jianchunfu@cmss.chinamobile.com> (jianchunfu@cmss.chinamobile.com's message of "Wed, 29 Jun 2022 11:15:52 +0800")

jianchunfu <jianchunfu@cmss.chinamobile.com> writes:

> Add error reporting before return when opening file fails.
>
> Signed-off-by: jianchunfu <jianchunfu@cmss.chinamobile.com>
> ---
>  target/ppc/kvm.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index dc93b99189..ef9a871411 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -1798,6 +1798,7 @@ static int read_cpuinfo(const char *field, char *value, int len)
>  
   static int read_cpuinfo(const char *field, char *value, int len)
   {
       FILE *f;
       int ret = -1;
       int field_len = strlen(field);
       char line[512];

>      f = fopen("/proc/cpuinfo", "r");
>      if (!f) {
> +        fprintf(stderr, "Error opening /proc/cpuinfo: %s\n", strerror(errno));
>          return -1;
>      }

       do {
           if (!fgets(line, sizeof(line), f)) {
               break;
           }
           if (!strncmp(line, field, field_len)) {
               pstrcpy(value, len, line);
               ret = 0;
               break;
           }
       } while (*line);

       fclose(f);

       return ret;
   }

This function now reports an error on one out of two failures.  The
caller can't tell whether it reported or not.

Please use error_report() for errors, warn_report() for warnings, and
info_report() for informational messages.

But is it an error?  Here's the only caller:

    static uint32_t kvmppc_get_tbfreq_procfs(void)
    {
        char line[512];
        char *ns;
        uint32_t tbfreq_fallback = NANOSECONDS_PER_SECOND;
        uint32_t tbfreq_procfs;

        if (read_cpuinfo("timebase", line, sizeof(line))) {
--->        return tbfreq_fallback;
        }

        ns = strchr(line, ':');
        if (!ns) {
--->        return tbfreq_fallback;
        }

        tbfreq_procfs = atoi(++ns);

        /* 0 is certainly not acceptable by the guest, return fallback value */
--->    return tbfreq_procfs ? tbfreq_procfs : tbfreq_fallback;
    }

I marked the three spots that handle errors.  All quietly return
NANOSECONDS_PER_SECOND.  The caller can't tell whether that happened.

Reporting an error when we don't actually fail is confusing.  Better
would be something like "Can't open /proc/cpuinfo, assuming timebase X",
where X is the value you assume.

Reporting this only in one out of several cases where we assume feels
wrong.  If it's worth reporting in one case, why isn't it worth
reporting in the other cases?  Is it worth reporting?

Aside: the use of atoi() silently maps a timebase of 0 to
NANOSECONDS_PER_SECOND.  Not fond of this function.  Not your patch's
problem, of course.

>  
> @@ -1906,6 +1907,7 @@ static uint64_t kvmppc_read_int_dt(const char *filename)
>  
>      f = fopen(filename, "rb");
>      if (!f) {
> +        fprintf(stderr, "Error opening %s: %s\n", filename, strerror(errno));
>          return -1;
>      }

Preexisting: this function returns -1 when fopen() fails, 0 when fread()
fails or read less data than expected.  Its caller
kvmppc_read_int_cpu_dt() passes on the return value.  However, it is
documented to return "0 if anything goes wrong".  Bug.  Not your patch's
fault, but it needs fixing.

Similar issue as above: you make the function emit an error message on
some, but not all failures.  If it's worth reporting in one case, why
isn't it worth reporting in the other cases?  Is it worth reporting?


  reply	other threads:[~2022-06-29  5:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-29  3:15 [PATCH] target/ppc: Add error reporting when opening file fails jianchunfu
2022-06-29  5:56 ` Markus Armbruster [this message]
2022-06-29 21:06   ` Daniel Henrique Barboza

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=87a69wrp0v.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=clg@kaod.org \
    --cc=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --cc=jianchunfu@cmss.chinamobile.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.