Re: blktest for [PATCH v2] block: do not use interruptible wait anywhere

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

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