From: Christoph Hellwig <hch@lst.de>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Jan Kara <jack@suse.cz>, "Darrick J . Wong" <djwong@kernel.org>,
linux-block@vger.kernel.org, Ming Lei <ming.lei@redhat.com>
Subject: Re: yet another approach to fix the loop lock order inversions v3
Date: Tue, 22 Mar 2022 12:12:22 +0100 [thread overview]
Message-ID: <20220322111222.GC28931@lst.de> (raw)
In-Reply-To: <18f892e5-09f9-ee87-b82b-5458d2f6d5cf@I-love.SAKURA.ne.jp>
On Wed, Mar 16, 2022 at 07:59:15PM +0900, Tetsuo Handa wrote:
> But I can see that due to no longer waiting for lo->lo_mutex from lo_open(),
> there are occasional I/O errors. What is your plan to avoid this?
There is no plan to avoid that. We'll get this areas due to have the
remove handling works. We could play tricks with RQF_QUIET, but I'm
not sure that is worth it.
> By the way, if CONFIG_BLOCK_LEGACY_AUTOLOAD=n,
>
> # mount -o loop,ro isofs.iso isofs/
>
> unconditionally fails with
>
> mount: isofs/: failed to setup loop device for isofs.iso.
>
> message. Commit 451f0b6f4c44d7b6 ("block: default BLOCK_LEGACY_AUTOLOAD to y")
> says "if the device node already exists because old scripts created it manually".
> But it is not always manual creation of loop devices; I think it is
> ioctl(LOOP_CTL_GET_FREE) in my case.
I'll take a look, thanks!
prev parent reply other threads:[~2022-03-22 11:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-16 8:45 yet another approach to fix the loop lock order inversions v3 Christoph Hellwig
2022-03-16 8:45 ` [PATCH 1/8] loop: de-duplicate the idle worker freeing code Christoph Hellwig
2022-03-16 8:45 ` [PATCH 2/8] loop: initialize the worker tracking fields once Christoph Hellwig
2022-03-16 9:26 ` Chaitanya Kulkarni
2022-03-16 8:45 ` [PATCH 3/8] loop: remove the racy bd_inode->i_mapping->nrpages asserts Christoph Hellwig
2022-03-16 10:24 ` Jan Kara
2022-03-16 8:45 ` [PATCH 4/8] loop: don't freeze the queue in lo_release Christoph Hellwig
2022-03-16 8:45 ` [PATCH 5/8] loop: only freeze the queue in __loop_clr_fd when needed Christoph Hellwig
2022-03-16 8:45 ` [PATCH 6/8] loop: implement ->free_disk Christoph Hellwig
2022-03-16 10:30 ` Jan Kara
2022-03-16 8:45 ` [PATCH 7/8] loop: remove lo_refcount and avoid lo_mutex in ->open / ->release Christoph Hellwig
2022-03-16 11:22 ` Jan Kara
2022-03-16 13:14 ` Tetsuo Handa
2022-03-16 14:38 ` Jan Kara
2022-03-22 11:09 ` Christoph Hellwig
2022-03-23 12:18 ` Jan Kara
2022-03-23 13:09 ` Tetsuo Handa
2022-03-16 8:45 ` [PATCH 8/8] loop: don't destroy lo->workqueue in __loop_clr_fd Christoph Hellwig
2022-03-16 11:25 ` Jan Kara
2022-03-16 13:24 ` Tetsuo Handa
2022-03-22 11:10 ` Christoph Hellwig
2022-03-22 12:42 ` Tetsuo Handa
2022-03-23 0:06 ` Tetsuo Handa
2022-03-16 10:59 ` yet another approach to fix the loop lock order inversions v3 Tetsuo Handa
2022-03-22 11:12 ` Christoph Hellwig [this message]
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=20220322111222.GC28931@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).