On 2021/11/25 20:26, Li Zhijian wrote:
> I tried
>
> export CFLAGS='-O2 -g -Wall -Werror -Wno-error=array-bounds'
You might need to pass extra CFLAGS in pkg/blktests/PKGBUILD where it builds the tests.
OK.
sed -i -e 's/make/make CFLAGS="-O2 -g -Wall -Werror
-Wno-error=array-bounds"/' pkg/blktests/PKGBUILD
worked.
> Can you provide the files related to
It could relate to below test
https://github.com/osandov/blktests/blob/master/tests/loop/006
>
>> Running loop/006
>> +losetup: /dev/loop0: failed to set up loop device: Invalid argument
>> Test complete
> line so that I can understand what this testcase is trying to do ?
Thank you. I think that this report was generated by serialization change
introduced by "loop: replace loop_validate_mutex with loop_validate_spinlock".
loop/006 was created for commit 310ca162d779efee ("block/loop: Use global lock
for ioctl() operation."). Commit 6cc8e7430801fa23 ("loop: scale loop device by
introducing per device lock") re-opened the race window and commit 3ce6e1f662a91097
("loop: reintroduce global lock for safe loop_validate_file() traversal") again
closed.
Since syzkaller finds circular locking dependency, locking for the loop module is
frequently changing. Commit c895b784c699224d ("loop: don't hold lo_mutex during
__loop_clr_fd()") which is scheduled for 5.17 stopped holding lo_mutex for
ioctl(LOOP_CLR_FD).
Then, "loop: replace loop_validate_mutex with loop_validate_spinlock" which is
waiting for
review at
https://lkml.kernel.org/r/84a861dc-6d50-81c0-8e8b-461ef59f4c01@i-love.sak...
is going to as well stop holding lo_mutex for ioctl(LOOP_SET_FD) / ioctl(LOOP_CONFIGURE)
/
ioctl(LOOP_CHANGE_FD). Technically, lo_mutex can be replaced with a global spinlock using
the same approach.
And "loop: replace loop_validate_mutex with loop_validate_spinlock" causes
loop_validate_file()
(where loop/006 was developed for) to observe Lo_binding state and returns -EINVAL, based
on
an assumption that it is a stupid request for administrator that one process tries to
tear down a loop device while other process tries to modify that loop device (in other
words,
"an insane attempt deserves an insane response"); as long as the kernel does not
crash,
returning an error when hitting a race window triggered by concurrent requests would be
fine.
I think that we need to drop (or update) loop/006 if "loop: replace
loop_validate_mutex with
loop_validate_spinlock" was accepted.