From: Jens Axboe <axboe@kernel.dk>
To: Alan Jenkins <alan.christopher.jenkins@gmail.com>,
Johannes Thumshirn <jthumshirn@suse.de>,
linux-block@vger.kernel.org
Cc: Bart Van Assche <Bart.VanAssche@wdc.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: blktest for [PATCH v2] block: do not use interruptible wait anywhere
Date: Sat, 14 Apr 2018 13:52:22 -0600 [thread overview]
Message-ID: <edda0c9e-93c3-2da1-9521-0775d41ca1c1@kernel.dk> (raw)
In-Reply-To: <d1ce87d6-f77c-96d0-a3df-5ee5ed73a0bf@gmail.com>
On 4/14/18 1:46 PM, Alan Jenkins wrote:
> On 13/04/18 09:31, Johannes Thumshirn wrote:
>> Hi Alan,
>>
>> On Thu, 2018-04-12 at 19:11 +0100, Alan Jenkins wrote:
>>> # dd if=/dev/sda of=/dev/null iflag=direct & \
>>> while killall -SIGUSR1 dd; do sleep 0.1; done & \
>>> echo mem > /sys/power/state ; \
>>> sleep 5; killall dd # stop after 5 seconds
>> Can you please also add a regression test to blktests[1] for this?
>>
>> [1] https://github.com/osandov/blktests
>>
>> Thanks,
>> Johannes
>
> Good question. It would be nice to promote this test.
>
> Template looks like I need the commit (sha1) first.
>
> I had some ideas about automating it, so I wrote a standalone (see
> end). I can automate the wakeup by using pm_test, but this is still a
> system suspend test. Unfortunately I don't think there's any
> alternative. To give the most dire example
>
> # This test is non-destructive, but it exercises suspend in all drivers.
> # If your system has a problem with suspend, it might not wake up again.
>
>
> So I'm not sure if it would be acceptable for the default set?
>
> How useful is this going to be? Is there an expanded/full set of tests
> that gets run somewhere?
>
> If you can't guarantee it's going to be run somewhere, I'd worry the
> cost/benefit feels a little narrow :-(. There were one or two further
> "interesting" details, and it might theoretically bitrot if it's not run
> periodically.
I run it, just last week we found two new bugs with it. I'm requiring
anyone that submits block patches to run the test suite, and also
working towards having it be part of the 0-day runs so it gets run
on posted patches automatically.
So yes, it's useful and it won't bitrot. Please do turn it into a blktests
test.
--
Jens Axboe
next prev parent reply other threads:[~2018-04-14 19:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-12 16:23 [PATCH] " Alan Jenkins
2018-04-12 17:51 ` Bart Van Assche
2018-04-12 18:11 ` [PATCH v2] " Alan Jenkins
2018-04-13 8:31 ` Johannes Thumshirn
2018-04-14 19:46 ` blktest for " Alan Jenkins
2018-04-14 19:52 ` Jens Axboe [this message]
2018-04-15 12:15 ` Alan Jenkins
2018-04-14 19:54 ` Jens Axboe
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=edda0c9e-93c3-2da1-9521-0775d41ca1c1@kernel.dk \
--to=axboe@kernel.dk \
--cc=Bart.VanAssche@wdc.com \
--cc=alan.christopher.jenkins@gmail.com \
--cc=jthumshirn@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.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
Powered by JetHome