qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Fam Zheng <famforupstream@gmail.com>
Cc: Fam Zheng <fam@euphon.net>, Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [PATCH] block: Introduce zero-co:// and zero-aio://
Date: Wed, 10 Mar 2021 15:49:13 +0100	[thread overview]
Message-ID: <557f59ec-ccbe-64a5-a21f-ab24dc818f2b@redhat.com> (raw)
In-Reply-To: <CAGNx5+34xWD33-YQmS_Tw-bV3nFMJSpB72c6paGpN4pdmmPkAg@mail.gmail.com>

On 3/10/21 3:28 PM, Fam Zheng wrote:
> On Wed, 10 Mar 2021 at 14:24, Philippe Mathieu-Daudé <philmd@redhat.com
> <mailto:philmd@redhat.com>> wrote:
> 
>     On 3/10/21 3:17 PM, fam@euphon.net <mailto:fam@euphon.net> wrote:
>     > From: Fam Zheng <famzheng@amazon.com <mailto:famzheng@amazon.com>>
>     >
>     > null-co:// has a read-zeroes=off default, when used to in security
>     > analysis, this can cause false positives because the driver doesn't
>     > write to the read buffer.
>     >
>     > null-co:// has the highest possible performance as a block driver, so
>     > let's keep it that way. This patch introduces zero-co:// and
>     > zero-aio://, largely similar with null-*://, but have
>     read-zeroes=on by
>     > default, so it's more suitable in cases than null-co://.
> 
>     Thanks!
> 
>     >
>     > Signed-off-by: Fam Zheng <fam@euphon.net <mailto:fam@euphon.net>>
>     > ---
>     >  block/null.c | 91
>     ++++++++++++++++++++++++++++++++++++++++++++++++++++
>     >  1 file changed, 91 insertions(+)
> 
>     > +static int zero_file_open(BlockDriverState *bs, QDict *options,
>     int flags,
>     > +                          Error **errp)
>     > +{
>     > +    QemuOpts *opts;
>     > +    BDRVNullState *s = bs->opaque;
>     > +    int ret = 0;
>     > +
>     > +    opts = qemu_opts_create(&runtime_opts, NULL, 0, &error_abort);
>     > +    qemu_opts_absorb_qdict(opts, options, &error_abort);
>     > +    s->length =
>     > +        qemu_opt_get_size(opts, BLOCK_OPT_SIZE, 1 << 30);
> 
>     Please do not use this magic default value, let's always explicit the
>     size.
> 
>         s->length = qemu_opt_get_size(opts, BLOCK_OPT_SIZE, 0);
>         if (s->length < 0) {
>             error_setg(errp, "%s is invalid", BLOCK_OPT_SIZE);
>             ret = -EINVAL;
>         }
> 
> 
> Doesn't that result in a bare
> 
>   -blockdev zero-co://
> 
> would have 0 byte in size?

Yes, this will display an error.

Maybe better something like:

    if (s->length == 0) {
        error_append_hint(errp, "Usage: zero-co://,size=NUM");
        error_setg(errp, "size must be specified");
        ret = -EINVAL;
    } else if (s->length < 0) {
        error_setg(errp, "%s is invalid", BLOCK_OPT_SIZE);
        ret = -EINVAL;
    }

> 
> I'm copying what null-co:// does today, and it's convenient for tests.
> Why is a default size bad?

We learned default are almost always bad because you can not get
rid of them. Also because we have reports of errors when using
floppy and another one (can't remember) with null-co because of
invalid size and we have to explain "the default is 1GB, you have
to explicit your size".

Phil.



  reply	other threads:[~2021-03-10 14:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 14:17 [PATCH] block: Introduce zero-co:// and zero-aio:// fam
2021-03-10 14:22 ` Philippe Mathieu-Daudé
2021-03-10 14:28   ` Fam Zheng
2021-03-10 14:49     ` Philippe Mathieu-Daudé [this message]
2021-03-10 14:59       ` Fam Zheng
2021-03-10 14:40 ` Vladimir Sementsov-Ogievskiy
2021-03-10 14:59   ` Fam Zheng
2021-03-10 14:59 ` Max Reitz
2021-03-10 16:35   ` Fam Zheng
2021-03-11 12:11     ` Max Reitz
2021-03-10 17:37 ` Kevin Wolf

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=557f59ec-ccbe-64a5-a21f-ab24dc818f2b@redhat.com \
    --to=philmd@redhat.com \
    --cc=fam@euphon.net \
    --cc=famforupstream@gmail.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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).