All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Anthony Iliopoulos <ailiop@suse.com>
Cc: Keith Busch <kbusch@kernel.org>,
	Anton Eidelman <anton@lightbitslabs.com>,
	Sagi Grimberg <sagi@grimberg.me>,
	linux-nvme@lists.infradead.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v2 for-5.8-rc 1/6] nvme: fix possible deadlock when I/O is blocked
Date: Wed, 8 Jul 2020 16:42:27 +0200	[thread overview]
Message-ID: <20200708144227.GA23255@lst.de> (raw)
In-Reply-To: <20200707105735.GA16868@technoir>

On Tue, Jul 07, 2020 at 12:57:35PM +0200, Anthony Iliopoulos wrote:
> The revalidation is still required there in order to update the blockdev
> size when multipath is enabled. With this revert, the behavior regressed
> back to before fab7772bfbcf, so the size isn't updated under multipath
> when the device is in use (e.g. mounted), it will only be effectively
> updated next time it is mounted as a side-effect of blkdev_open on first
> opener. This prevents online resizing of filesystems.
> 
> > And if you look at revalidate, it only calls fops->revalidate_disk
> > (which is a noop in the mpath device) and checks the size change.
> 
> The mpath gendisk doesn't have a revalidate_disk fop indeed, but call to
> check_disk_size_change was needed to update its size. Otherwise, the
> size change isn't reflected externally to userspace before next mount.
> cb224c3af4df doesn't fix this as it skips revalidate and thus also skips
> updating the size.
> 
> The issue is that under CONFIG_NVME_MULTIPATH=y the ns->disk becomes a
> hidden gendisk (see nvme_set_disk_name) and thus doesn't have a backing
> bdev, while ns->head->disk becomes the "visible" one to userspace (with
> a backing bdev), and therefore needs its bdev->bd_inode->i_size updated
> when resized.
> 
> The following patch seems to be working, although I'm not sufficiently
> familiar with the code to tell if this won't cause any other deadlocks
> with some confidence:

This looks sensible to me.  Sagi?

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2020-07-08 14:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24  0:18 [PATCH v2 for-5.8-rc 0/6] address deadlocks in high stress ns scanning and ana updates Sagi Grimberg
2020-06-24  0:18 ` [PATCH v2 for-5.8-rc 1/6] nvme: fix possible deadlock when I/O is blocked Sagi Grimberg
2020-06-24  6:29   ` Christoph Hellwig
2020-06-24  6:54     ` Sagi Grimberg
2020-06-24  6:57       ` Christoph Hellwig
2020-06-24  7:09         ` Sagi Grimberg
2020-07-07 10:57       ` Anthony Iliopoulos
2020-07-08 14:42         ` Christoph Hellwig [this message]
2020-07-10  4:47           ` Sagi Grimberg
2020-07-14 11:12         ` Christoph Hellwig
2020-06-24  0:18 ` [PATCH v2 for-5.8-rc 2/6] nvme-multipath: fix deadlock between ana_work and scan_work Sagi Grimberg
2020-06-24  6:34   ` Christoph Hellwig
2020-06-24  6:56     ` Sagi Grimberg
2020-06-24  0:18 ` [PATCH v2 for-5.8-rc 3/6] nvme: don't protect ns mutation with ns->head->lock Sagi Grimberg
2020-06-24  6:37   ` Christoph Hellwig
2020-06-24  6:58     ` Sagi Grimberg
2020-06-24  8:24     ` Sagi Grimberg
2020-06-24  0:18 ` [PATCH v2 for-5.8-rc 4/6] nvme-multipath: fix deadlock due to head->lock Sagi Grimberg
2020-06-24  6:39   ` Christoph Hellwig
2020-06-24  7:00     ` Sagi Grimberg
2020-06-24  0:18 ` [PATCH v2 for-5.8-rc 5/6] nvme-multipath: fix bogus request queue reference put Sagi Grimberg
2020-06-24  6:40   ` Christoph Hellwig
2020-06-24  0:18 ` [PATCH v2 RFC 6/6] nvme-core: fix deadlock in disconnect during scan_work and/or ana_work Sagi Grimberg
2020-06-24  6:43   ` Christoph Hellwig
2020-06-24  7:13     ` Sagi Grimberg

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=20200708144227.GA23255@lst.de \
    --to=hch@lst.de \
    --cc=ailiop@suse.com \
    --cc=anton@lightbitslabs.com \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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.