| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID:
<IA1PR10MB7240DE46976A3B027DE5484998D22@IA1PR10MB7240.namprd10.prod.outlook.com>
Date: Sun, 30 Jun 2024 22:11:14 +0000
From: Gulam Mohamed <gulam.mohamed@...cle.com>
To: "hch@....de" <hch@....de>
CC: "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"yukuai1@...weicloud.com" <yukuai1@...weicloud.com>,
"axboe@...nel.dk"
<axboe@...nel.dk>
Subject: RE: [PATCH V6 for-6.11/block] loop: Fix a race between loop detach
and loop open
Hi Christoph,
With our latest version of the patch V6, the "kernel robot test" failed in the ioctl_loop06 test (LTP tests) as in below mail.
The reason for the failure is, the deferring of the "detach" loop device to release function. The test opens the loop device, sends LOOP_SET_BLOCK_SIZE and LOOP_CONFIGURE commands and in between that, it will also detach the loop device. At the end of the test, while cleanup, it will close the loop device. As we deferred the detach to last close, the detach will be at the end only but before that we are setting the lo_state to Lo_rundown. This setting of Lo_rundown we are doing in the beginning because, there was another LTP test case failed earlier due to the same reason.
So, when the LOOP_CONFIGURE was sent, the loop device was still in Lo_rundown state (Lo_unbound will be set after detach in __loop_clr_fd()) due to which kernel returned the EBUSY error causing the test to fail.
I have noticed that a good number of test cases are having a behaviour that it will send different loop commands and in between the detach command also, with only a single open. And close happens at the end. Due to this, I think a couple of test cases needs to be modified.
Now, as per my understanding, we have two options here:
1. Continue with this kernel patch and modify few test cases to accommodate this new kernel behaviour
2. Go back to using the lo_refcnt
The first option doesn't seem to be flexible as we need to modify a good number of test cases.
Can you please correct if I am missing anything and suggest how to proceed?
Regards,
Gulam Mohamed.
> -----Original Message-----
> From: kernel test robot <oliver.sang@...el.com>
> Sent: Friday, June 28, 2024 11:09 AM
> To: Gulam Mohamed <gulam.mohamed@...cle.com>
> Cc: oe-lkp@...ts.linux.dev; lkp@...el.com; linux-block@...r.kernel.org;
> ltp@...ts.linux.it; linux-kernel@...r.kernel.org; yukuai1@...weicloud.com;
> hch@....de; axboe@...nel.dk; oliver.sang@...el.com
> Subject: Re: [PATCH V6 for-6.11/block] loop: Fix a race between loop detach
> and loop open
>
>
>
> Hello,
>
> kernel test robot noticed "ltp.ioctl_loop06.fail" on:
>
> commit: a167a9996e22ae0d108307fbc66b811d821ffbe7 ("[PATCH V6 for-
> 6.11/block] loop: Fix a race between loop detach and loop open")
> url: https://urldefense.com/v3/__https://github.com/intel-lab-
> lkp/linux/commits/Gulam-Mohamed/loop-Fix-a-race-between-loop-detach-
> and-loop-open/20240619-
> 004334__;!!ACWV5N9M2RV99hQ!KYjjKXzy4egkNOv4NcO0tNoEVElMSquM5Riz
> BqquFexq6ScoztvIJUysVnUfltmEDSSy4LXCb1bKijp8xq-V_CM$
> base:
> https://urldefense.com/v3/__https://git.kernel.org/cgit/linux/kernel/git/axboe
> /linux-
> block.git__;!!ACWV5N9M2RV99hQ!KYjjKXzy4egkNOv4NcO0tNoEVElMSquM5Ri
> zBqquFexq6ScoztvIJUysVnUfltmEDSSy4LXCb1bKijp8JTiEzBw$ for-next patch
> link:
> https://urldefense.com/v3/__https://lore.kernel.org/all/20240618164042.343
> 777-1-
> gulam.mohamed@...cle.com/__;!!ACWV5N9M2RV99hQ!KYjjKXzy4egkNOv4
> NcO0tNoEVElMSquM5RizBqquFexq6ScoztvIJUysVnUfltmEDSSy4LXCb1bKijp8v
> DJnm-A$
> patch subject: [PATCH V6 for-6.11/block] loop: Fix a race between loop detach
> and loop open
>
> in testcase: ltp
> version: ltp-x86_64-14c1f76-1_20240615
> with following parameters:
>
> disk: 1HDD
> fs: f2fs
> test: syscalls-01/ioctl_loop06
>
>
>
> compiler: gcc-13
> test machine: 4 threads 1 sockets Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz
> (Ivy Bridge) with 8G memory
>
> (please refer to attached dmesg/kmsg for entire log/backtrace)
>
>
>
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@...el.com>
> | Closes:
> | https://urldefense.com/v3/__https://lore.kernel.org/oe-lkp/20240628135
> | 0.b7298127-
> oliver.sang@...el.com__;!!ACWV5N9M2RV99hQ!KYjjKXzy4egkNOv4N
> |
> cO0tNoEVElMSquM5RizBqquFexq6ScoztvIJUysVnUfltmEDSSy4LXCb1bKijp8aKJi
> x68
> | $
>
>
>
> Running tests.......
> <<<test_start>>>
> tag=ioctl_loop06 stime=1719063458
> cmdline="ioctl_loop06"
> contacts=""
> analysis=exit
> <<<test_output>>>
> tst_test.c:1734: TINFO: LTP version: 20240524-41-g248223546
> tst_test.c:1618: TINFO: Timeout per run is 0h 02m 30s
> tst_device.c:96: TINFO: Found free device 0 '/dev/loop0'
> ioctl_loop06.c:74: TINFO: Using LOOP_SET_BLOCK_SIZE with arg < 512
> ioctl_loop06.c:65: TPASS: Set block size failed as expected: EINVAL (22)
> ioctl_loop06.c:74: TINFO: Using LOOP_SET_BLOCK_SIZE with arg > PAGE_SIZE
> ioctl_loop06.c:65: TPASS: Set block size failed as expected: EINVAL (22)
> ioctl_loop06.c:74: TINFO: Using LOOP_SET_BLOCK_SIZE with arg !=
> power_of_2
> ioctl_loop06.c:65: TPASS: Set block size failed as expected: EINVAL (22)
> ioctl_loop06.c:74: TINFO: Using LOOP_CONFIGURE with block_size < 512
> ioctl_loop06.c:67: TFAIL: Set block size failed expected EINVAL got: EBUSY (16)
> ioctl_loop06.c:74: TINFO: Using LOOP_CONFIGURE with block_size >
> PAGE_SIZE
> ioctl_loop06.c:67: TFAIL: Set block size failed expected EINVAL got: EBUSY (16)
> ioctl_loop06.c:74: TINFO: Using LOOP_CONFIGURE with block_size !=
> power_of_2
> ioctl_loop06.c:67: TFAIL: Set block size failed expected EINVAL got: EBUSY (16)
>
> Summary:
> passed 3
> failed 3
> broken 0
> skipped 0
> warnings 0
> incrementing stop
> <<<execution_status>>>
> initiation_status="ok"
> duration=0 termination_type=exited termination_id=1 corefile=no
> cutime=0 cstime=3
> <<<test_end>>>
> INFO: ltp-pan reported some tests FAIL
> LTP Version: 20240524-41-g248223546
>
>
> ###############################################################
>
> Done executing testcases.
> LTP Version: 20240524-41-g248223546
>
> ###############################################################
>
>
>
>
> The kernel config and materials to reproduce are available at:
> https://urldefense.com/v3/__https://download.01.org/0day-
> ci/archive/20240628/202406281350.b7298127-
> oliver.sang@...el.com__;!!ACWV5N9M2RV99hQ!KYjjKXzy4egkNOv4NcO0tNoE
> VElMSquM5RizBqquFexq6ScoztvIJUysVnUfltmEDSSy4LXCb1bKijp8ZxsxyCs$
>
>
>
> --
> 0-DAY CI Kernel Test Service
> https://urldefense.com/v3/__https://github.com/intel/lkp-
> tests/wiki__;!!ACWV5N9M2RV99hQ!KYjjKXzy4egkNOv4NcO0tNoEVElMSquM5
> RizBqquFexq6ScoztvIJUysVnUfltmEDSSy4LXCb1bKijp8xUKSK2Y$
Powered by blists - more mailing lists