All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Ian Jackson <iwj@xenproject.org>,
	Kevin Stefanov <kevin.stefanov@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
	Julien Grall <julien@xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2] tools/tests: Make E2BIG non-fatal to xenstore unit test
Date: Fri, 15 Oct 2021 17:07:32 +0200	[thread overview]
Message-ID: <227b70e9-23c1-1aaa-4e77-1c64ba8f24ae@suse.com> (raw)
In-Reply-To: <24937.32544.417730.402070@mariner.uk.xensource.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 1521 bytes --]

On 15.10.21 15:16, Ian Jackson wrote:
> Kevin Stefanov writes ("[PATCH v2] tools/tests: Make E2BIG non-fatal to xenstore unit test"):
>> Xenstore's unit test fails on read and write of big numbers if
>> quota-maxsize is set to a lower number than those test cases use.
>>
>> Output a special warning instead of a failure message in such cases
>> and make the error non-fatal to the unit test.
> 
> I realise that I am late to this, but I'm not sure I agree with the
> basic principle of this change.  In general tolerating particular
> errors in a test, and simply abandoning the test if they occcur, is
> normally not the best approach.
> 
> Questions that come to my mind (and which aren't answered in the
> commit message and probably should be) include:
> 
> Why does test-xenstore using these large numbers for its tests ?

For testing large data packets.

> Why would you run the tests with a quota too low for the tests ?

Good question.

> Might this test change not in principle miss genuine bugs ?

Yes, e.g. if a test returns E2BIG even if it shouldn't.

So I agree to being more cautious here.

Maybe a parameter could be added to limit the allowed data size?
Then the "large data" test could be adjusted to not send more data
than allowed (it should be noted that the node size quota is
including data, names of children, and access right entries, so
the pure node data should be selected with some spare size in
mind, e.g. 100 bytes smaller than the quota).


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

      reply	other threads:[~2021-10-15 15:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-15 12:14 [PATCH v2] tools/tests: Make E2BIG non-fatal to xenstore unit test Kevin Stefanov
2021-10-15 12:21 ` Jan Beulich
2021-10-15 13:16 ` Ian Jackson
2021-10-15 15:07   ` Juergen Gross [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=227b70e9-23c1-1aaa-4e77-1c64ba8f24ae@suse.com \
    --to=jgross@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=julien@xen.org \
    --cc=kevin.stefanov@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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.