| Message ID | 20180724084739.580-1-famz@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | iotests: Fix 226 on _my_ system | expand |
On 07/24/2018 03:47 AM, Fam Zheng wrote: > Something has locked /dev/null on my system (I still don't know what to do with > the annoying incapability of lslocks, or more precisely /proc/locks, on > inspecting OFD lock information), and as a result 226 cannot pass due to the > unexpected image locking error. > > Fix the test case by disabling locking, and add a doc text about using test > images. > > Fam Zheng (2): > docs: Describe using images in writing iotests > iotests: Don't lock /dev/null in 226 > Reviewed-by: Eric Blake <eblake@redhat.com> > docs/devel/testing.rst | 11 +++++++++++ > tests/qemu-iotests/226 | 4 ++-- > 2 files changed, 13 insertions(+), 2 deletions(-) >
On 07/24/2018 04:47 AM, Fam Zheng wrote: > Something has locked /dev/null on my system (I still don't know what to do with > the annoying incapability of lslocks, or more precisely /proc/locks, on > inspecting OFD lock information), and as a result 226 cannot pass due to the > unexpected image locking error. > > Fix the test case by disabling locking, and add a doc text about using test > images. > > Fam Zheng (2): > docs: Describe using images in writing iotests > iotests: Don't lock /dev/null in 226 > > docs/devel/testing.rst | 11 +++++++++++ > tests/qemu-iotests/226 | 4 ++-- > 2 files changed, 13 insertions(+), 2 deletions(-) > I think this is the better approach for now, yeah. Sorry my test caused so many problems... :[ Reviewed-by: John Snow <jsnow@redhat.com>
On Tue, 07/24 16:47, Fam Zheng wrote: > Something has locked /dev/null on my system (I still don't know what to do with > the annoying incapability of lslocks, or more precisely /proc/locks, on > inspecting OFD lock information), and as a result 226 cannot pass due to the > unexpected image locking error. > > Fix the test case by disabling locking, and add a doc text about using test > images. > > Fam Zheng (2): > docs: Describe using images in writing iotests > iotests: Don't lock /dev/null in 226 > > docs/devel/testing.rst | 11 +++++++++++ > tests/qemu-iotests/226 | 4 ++-- > 2 files changed, 13 insertions(+), 2 deletions(-) Kevin, could you apply this for 3.0 too? Fam
Am 27.07.2018 um 11:24 hat Fam Zheng geschrieben: > On Tue, 07/24 16:47, Fam Zheng wrote: > > Something has locked /dev/null on my system (I still don't know what to do with > > the annoying incapability of lslocks, or more precisely /proc/locks, on > > inspecting OFD lock information), and as a result 226 cannot pass due to the > > unexpected image locking error. > > > > Fix the test case by disabling locking, and add a doc text about using test > > images. > > > > Fam Zheng (2): > > docs: Describe using images in writing iotests > > iotests: Don't lock /dev/null in 226 > > > > docs/devel/testing.rst | 11 +++++++++++ > > tests/qemu-iotests/226 | 4 ++-- > > 2 files changed, 13 insertions(+), 2 deletions(-) > > Kevin, could you apply this for 3.0 too? Sure, applied to the block branch. Out of curiosity, did you find out what had locked the devices? Kevin
On Fri, Jul 27, 2018 at 6:04 PM Kevin Wolf <kwolf@redhat.com> wrote: > > Am 27.07.2018 um 11:24 hat Fam Zheng geschrieben: > > On Tue, 07/24 16:47, Fam Zheng wrote: > > > Something has locked /dev/null on my system (I still don't know what to do with > > > the annoying incapability of lslocks, or more precisely /proc/locks, on > > > inspecting OFD lock information), and as a result 226 cannot pass due to the > > > unexpected image locking error. > > > > > > Fix the test case by disabling locking, and add a doc text about using test > > > images. > > > > > > Fam Zheng (2): > > > docs: Describe using images in writing iotests > > > iotests: Don't lock /dev/null in 226 > > > > > > docs/devel/testing.rst | 11 +++++++++++ > > > tests/qemu-iotests/226 | 4 ++-- > > > 2 files changed, 13 insertions(+), 2 deletions(-) > > > > Kevin, could you apply this for 3.0 too? > > Sure, applied to the block branch. > > Out of curiosity, did you find out what had locked the devices? No, but I'll for sure allocate some time to understand kernel's OFD internals, find the holder application, then hopefully, propose something that can fix lslocks. Thanks, Fam > > Kevin