All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.cz>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Jens Axboe <axboe@kernel.dk>, Josef Bacik <josef@toxicpanda.com>,
	Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>,
	"Darrick J . Wong" <djwong@kernel.org>,
	Ming Lei <ming.lei@redhat.com>,
	Matteo Croce <mcroce@microsoft.com>,
	linux-block@vger.kernel.org, nbd@other.debian.org
Subject: Re: yet another approach to fix the loop lock order inversions v6
Date: Tue, 5 Apr 2022 11:10:03 +0200	[thread overview]
Message-ID: <20220405091003.gmeuhtrwj7nzebyx@quack3.lan> (raw)
In-Reply-To: <20220405062838.GA24373@lst.de>

On Tue 05-04-22 08:28:38, Christoph Hellwig wrote:
> On Mon, Apr 04, 2022 at 06:39:31PM +0900, Tetsuo Handa wrote:
> > Two bugs which Jan has found in /bin/mount might not be yet fixed in
> > versions developers/users are using. Thus, let's wait for a while
> > before committing to linux.git.
> 
> Jan, which loop bugs might be relevant here?

So there was a bug in libmount code trying to reuse already setup loop
devices and changes in timing & removing the lo_mutex from lo_open() +
suitable racing with systemd-udev probing devices caused these bugs to
manifest. The visible effect was that a loop like:

while :; do mount -o loop,ro isofs.iso isofs/; umount isofs/; done

often failed with:

mount: /mnt: can't read superblock on /dev/loop0.
umount: /mnt: not mounted.

Bugs are fixed now by commits 3e1fc3bbe ("mount: Fix race in loop device
reuse code"), fb4b6b115 ("loopdev: Properly translate errors from
ul_path_read_*()"), 562990b552 ("loopdev: Do not treat errors when
detecting overlap as fatal") in util-linux git.

The only real-world impact I've heard about was LTP failing due to these
problems and those guys should be capable enough to update their util-linux
when we tell them. So I think we should be OK with pushing the kernel fixes
upstream but it may generate some noise from automated testers before
util-linux is updated on all of them...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  parent reply	other threads:[~2022-04-05  9:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30  5:29 yet another approach to fix the loop lock order inversions v6 Christoph Hellwig
2022-03-30  5:29 ` [PATCH 01/15] nbd: use the correct block_device in nbd_bdev_reset Christoph Hellwig
2022-04-18 12:54   ` Jens Axboe
2022-03-30  5:29 ` [PATCH 02/15] zram: cleanup reset_store Christoph Hellwig
2022-03-30  5:29 ` [PATCH 03/15] zram: cleanup zram_remove Christoph Hellwig
2022-03-30  5:29 ` [PATCH 04/15] block: add a disk_openers helper Christoph Hellwig
2022-03-30  5:29 ` [PATCH 05/15] block: turn bdev->bd_openers into an atomic_t Christoph Hellwig
2022-03-30  5:29 ` [PATCH 06/15] loop: de-duplicate the idle worker freeing code Christoph Hellwig
2022-03-30  5:29 ` [PATCH 07/15] loop: initialize the worker tracking fields once Christoph Hellwig
2022-03-30  5:29 ` [PATCH 08/15] loop: remove the racy bd_inode->i_mapping->nrpages asserts Christoph Hellwig
2022-03-30  5:29 ` [PATCH 09/15] loop: don't freeze the queue in lo_release Christoph Hellwig
2022-03-30  5:29 ` [PATCH 10/15] loop: only freeze the queue in __loop_clr_fd when needed Christoph Hellwig
2022-03-30  5:29 ` [PATCH 11/15] loop: implement ->free_disk Christoph Hellwig
2022-03-30  5:29 ` [PATCH 12/15] loop: suppress uevents while reconfiguring the device Christoph Hellwig
2022-03-30  5:29 ` [PATCH 13/15] loop: avoid loop_validate_mutex/lo_mutex in ->release Christoph Hellwig
2022-03-30  5:29 ` [PATCH 14/15] loop: remove lo_refcount and avoid lo_mutex in ->open / ->release Christoph Hellwig
2022-03-30  5:29 ` [PATCH 15/15] loop: don't destroy lo->workqueue in __loop_clr_fd Christoph Hellwig
2022-04-04  7:42 ` yet another approach to fix the loop lock order inversions v6 Christoph Hellwig
2022-04-04  9:39   ` Tetsuo Handa
2022-04-05  6:28     ` Christoph Hellwig
2022-04-05  6:38       ` Tetsuo Handa
2022-04-05  9:10       ` Jan Kara [this message]
2022-04-18  9:39     ` Tetsuo Handa

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=20220405091003.gmeuhtrwj7nzebyx@quack3.lan \
    --to=jack@suse.cz \
    --cc=axboe@kernel.dk \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=josef@toxicpanda.com \
    --cc=linux-block@vger.kernel.org \
    --cc=mcroce@microsoft.com \
    --cc=minchan@kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=nbd@other.debian.org \
    --cc=ngupta@vflare.org \
    --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 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.