From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v3] squashfs: Add regression test for sanity check bug
Date: Wed, 21 Jul 2021 13:47:54 +0200 [thread overview]
Message-ID: <YPgJan6PMGu+Pb/J@yuki> (raw)
In-Reply-To: <f2fd323e-a5da-2959-d130-2d3c0aa59e89@jv-coder.de>
Hi!
> > Also the dev_min_size = 1 does not have any efect here, since it can be
> > used only to request bigger-than-default size and gets ignored here. I
> > guess that we can merge this as it is and I will add needs_loopdev to
> > the tst_test structure later which will just allocate loop device and
> > pass it down to the test.
> This is true, but the test should also specify what it needs. If for
> whatever reason DEV_SIZE_MB is redefined to a smaller value, the test
> would still work.
> To be honest, for "1" it doesn't matter. But it it was bigger, it makes
> total sense to specify the size if the test knows it...
I was thinking about it and we can easily allow the test to request
smaller than the default size with a pretty minimal change:
diff --git a/lib/tst_device.c b/lib/tst_device.c
index c91c6cd55..4ef802c41 100644
--- a/lib/tst_device.c
+++ b/lib/tst_device.c
@@ -300,7 +300,7 @@ const char *tst_acquire_device__(unsigned int size)
unsigned int acq_dev_size;
uint64_t ltp_dev_size;
- acq_dev_size = MAX(size, DEV_SIZE_MB);
+ acq_dev_size = size ? size : DEV_SIZE_MB;
dev = getenv("LTP_DEV");
This shouldn't break anything while it allows better controll for the
test over the device size.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2021-07-21 11:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-15 5:08 [LTP] [PATCH v3] squashfs: Add regression test for sanity check bug Joerg Vehlow
2021-07-15 8:00 ` Richard Palethorpe
2021-07-15 8:21 ` xuyang2018.jy
2021-07-15 8:44 ` Joerg Vehlow
2021-07-15 9:27 ` Cyril Hrubis
2021-07-15 10:12 ` Joerg Vehlow
2021-07-15 10:09 ` Cyril Hrubis
2021-07-15 10:40 ` Joerg Vehlow
2021-07-21 11:47 ` Cyril Hrubis [this message]
2021-08-04 14:05 ` Cyril Hrubis
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=YPgJan6PMGu+Pb/J@yuki \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/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