From: "hch@lst.de" <hch@lst.de>
To: Gulam Mohamed <gulam.mohamed@oracle.com>
Cc: kernel test robot <oliver.sang@intel.com>,
"oe-lkp@lists.linux.dev" <oe-lkp@lists.linux.dev>,
"lkp@intel.com" <lkp@intel.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"ltp@lists.linux.it" <ltp@lists.linux.it>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"yukuai1@huaweicloud.com" <yukuai1@huaweicloud.com>,
"hch@lst.de" <hch@lst.de>, "axboe@kernel.dk" <axboe@kernel.dk>
Subject: Re: [PATCH V4 for-6.10/block] loop: Fix a race between loop detach and loop open
Date: Fri, 14 Jun 2024 07:45:34 +0200 [thread overview]
Message-ID: <20240614054534.GA9969@lst.de> (raw)
In-Reply-To: <IA1PR10MB7240B2686664744DB0D8867F98C12@IA1PR10MB7240.namprd10.prod.outlook.com>
On Thu, Jun 13, 2024 at 09:10:37PM +0000, Gulam Mohamed wrote:
> I looked at the LTP test case failure and also the function tst_detach_device_by_fd() which failed. Our kernel patch will defer all the attempts to detach a loop device to the last close, to fix an issue.
> The tst_detach_device_by_fd() in LTP test case will open the loop device and repeatedly checks for error code ENXIO. As the new approach, as I mentioned above, will defer the detach to last close and the last close happens *only* when the LTP test function tst_detach_device_by_fd() returns, the test will obviously fail. So, Can you please modify the LTP test case to accommodate the new behaviour of kernel code for loop detach?
> Please let us know your comments.
I still think simply setting the rundown state is the better approach..
WARNING: multiple messages have this Message-ID (diff)
From: "hch@lst.de" <hch@lst.de>
To: Gulam Mohamed <gulam.mohamed@oracle.com>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
"lkp@intel.com" <lkp@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"yukuai1@huaweicloud.com" <yukuai1@huaweicloud.com>,
kernel test robot <oliver.sang@intel.com>,
"oe-lkp@lists.linux.dev" <oe-lkp@lists.linux.dev>,
"hch@lst.de" <hch@lst.de>,
"ltp@lists.linux.it" <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH V4 for-6.10/block] loop: Fix a race between loop detach and loop open
Date: Fri, 14 Jun 2024 07:45:34 +0200 [thread overview]
Message-ID: <20240614054534.GA9969@lst.de> (raw)
In-Reply-To: <IA1PR10MB7240B2686664744DB0D8867F98C12@IA1PR10MB7240.namprd10.prod.outlook.com>
On Thu, Jun 13, 2024 at 09:10:37PM +0000, Gulam Mohamed wrote:
> I looked at the LTP test case failure and also the function tst_detach_device_by_fd() which failed. Our kernel patch will defer all the attempts to detach a loop device to the last close, to fix an issue.
> The tst_detach_device_by_fd() in LTP test case will open the loop device and repeatedly checks for error code ENXIO. As the new approach, as I mentioned above, will defer the detach to last close and the last close happens *only* when the LTP test function tst_detach_device_by_fd() returns, the test will obviously fail. So, Can you please modify the LTP test case to accommodate the new behaviour of kernel code for loop detach?
> Please let us know your comments.
I still think simply setting the rundown state is the better approach..
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2024-06-14 5:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-07 19:06 [PATCH V4 for-6.10/block] loop: Fix a race between loop detach and loop open Gulam Mohamed
2024-06-08 5:20 ` Christoph Hellwig
2024-06-10 3:44 ` Chaitanya Kulkarni
2024-06-11 14:58 ` kernel test robot
2024-06-11 14:58 ` [LTP] " kernel test robot
2024-06-13 21:10 ` Gulam Mohamed
2024-06-13 21:10 ` [LTP] " Gulam Mohamed via ltp
2024-06-14 5:45 ` hch [this message]
2024-06-14 5:45 ` hch
2024-06-14 23:35 ` Gulam Mohamed
2024-06-14 23:35 ` [LTP] " Gulam Mohamed via ltp
2024-06-12 5:19 ` Christoph Hellwig
2025-03-31 14:10 ` Zhu Yanjun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240614054534.GA9969@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=gulam.mohamed@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=ltp@lists.linux.it \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=yukuai1@huaweicloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.