Messages in this thread |  | | Subject | Re: blktest for [PATCH v2] block: do not use interruptible wait anywhere | From | Alan Jenkins <> | Date | Sun, 15 Apr 2018 13:15:35 +0100 |
| |
On 14/04/18 20:52, Jens Axboe wrote: > 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.
Thanks, it's really great to have a test suite. I was specifically checking in on how we can include a system suspend test.
I've been thinking the suspend test could be opt-in test (e.g. ALLOW_PM_TEST=1), and then we have some infrastructure (you or 0-day runs) that does the opt-in. Without knowing anything about the infrastructure, I didn't want to assume that would work.
I'm aware of one particular suspend issue; inside virt-manager VMs I see Linux crashing with a null pointer in qxl_drm_freeze. A regression soon after I learned how to use VMs for suspend tests :-( , and it's been long enough that I suspect few people use it.
Partly what you saw me fishing for in the comments, is the idea of some kernel code allowing more direct testing of the queue freeze / preempt_only flag. That might be better engineering, but I don't know where I could put it.
Alan
|  |