From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: Justin Sanders <justin@coraid.com>,
Josef Bacik <josef@toxicpanda.com>,
Xianting Tian <xianting_tian@126.com>,
linux-block@vger.kernel.org, dm-devel@redhat.com,
Stefan Haberland <sth@linux.ibm.com>,
Jan Hoeppner <hoeppner@linux.ibm.com>,
linux-kernel@vger.kernel.org, nbd@other.debian.org,
linux-nvme@lists.infradead.org, linux-s390@vger.kernel.org
Subject: Re: fix block device size update serialization v2
Date: Thu, 27 Aug 2020 09:47:58 +0200 [thread overview]
Message-ID: <20200827074758.GA8009@lst.de> (raw)
In-Reply-To: <20200823091043.2600261-1-hch@lst.de>
Jens, can you consider this for 5.9? It reliably fixes the reported
hangs with nvme hotremoval that we've had for a few releases.
On Sun, Aug 23, 2020 at 11:10:40AM +0200, Christoph Hellwig wrote:
> Hi Jens,
>
> this series fixes how we update i_size for the block device inodes (and
> thus the block device). Different helpers use two different locks
> (bd_mutex and i_rwsem) to protect the update, and it appears device
> mapper uses yet another internal lock. A lot of the drivers do the
> update handcrafted in often crufty ways. And in addition to that mess
> it turns out that the "main" lock, bd_mutex is pretty dead lock prone
> vs other spots in the block layer that acquire it during revalidation
> operations, as reported by Xianting.
>
> Fix all that by adding a dedicated spinlock just for the size updates.
>
> Changes since v1:
> - don't call __invalidate_device under the new spinlock
> - don't call into the file system code from the nvme removal code
---end quoted text---
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-s390@vger.kernel.org, Jan Hoeppner <hoeppner@linux.ibm.com>,
Justin Sanders <justin@coraid.com>,
linux-nvme@lists.infradead.org,
Josef Bacik <josef@toxicpanda.com>,
Xianting Tian <xianting_tian@126.com>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
dm-devel@redhat.com, Stefan Haberland <sth@linux.ibm.com>,
nbd@other.debian.org
Subject: Re: fix block device size update serialization v2
Date: Thu, 27 Aug 2020 09:47:58 +0200 [thread overview]
Message-ID: <20200827074758.GA8009@lst.de> (raw)
In-Reply-To: <20200823091043.2600261-1-hch@lst.de>
Jens, can you consider this for 5.9? It reliably fixes the reported
hangs with nvme hotremoval that we've had for a few releases.
On Sun, Aug 23, 2020 at 11:10:40AM +0200, Christoph Hellwig wrote:
> Hi Jens,
>
> this series fixes how we update i_size for the block device inodes (and
> thus the block device). Different helpers use two different locks
> (bd_mutex and i_rwsem) to protect the update, and it appears device
> mapper uses yet another internal lock. A lot of the drivers do the
> update handcrafted in often crufty ways. And in addition to that mess
> it turns out that the "main" lock, bd_mutex is pretty dead lock prone
> vs other spots in the block layer that acquire it during revalidation
> operations, as reported by Xianting.
>
> Fix all that by adding a dedicated spinlock just for the size updates.
>
> Changes since v1:
> - don't call __invalidate_device under the new spinlock
> - don't call into the file system code from the nvme removal code
---end quoted text---
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-08-27 7:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-23 9:10 fix block device size update serialization v2 Christoph Hellwig
2020-08-23 9:10 ` Christoph Hellwig
2020-08-23 9:10 ` [PATCH 1/3] block: replace bd_set_size with bd_set_nr_sectors Christoph Hellwig
2020-08-23 9:10 ` Christoph Hellwig
2020-08-24 8:25 ` Sagi Grimberg
2020-08-24 8:25 ` Sagi Grimberg
2020-08-23 9:10 ` [PATCH 2/3] block: fix locking for struct block_device size updates Christoph Hellwig
2020-08-23 9:10 ` Christoph Hellwig
2020-08-24 7:36 ` Hannes Reinecke
2020-08-24 7:36 ` Hannes Reinecke
2020-08-24 8:26 ` Sagi Grimberg
2020-08-24 8:26 ` Sagi Grimberg
2020-08-23 9:10 ` [PATCH 3/3] nvme: don't call revalidate_disk from nvme_set_queue_dying Christoph Hellwig
2020-08-23 9:10 ` Christoph Hellwig
2020-08-24 7:37 ` Hannes Reinecke
2020-08-24 7:37 ` Hannes Reinecke
2020-08-24 8:26 ` Sagi Grimberg
2020-08-24 8:26 ` Sagi Grimberg
2020-08-27 7:47 ` Christoph Hellwig [this message]
2020-08-27 7:47 ` fix block device size update serialization v2 Christoph Hellwig
2020-08-29 16:47 ` Jens Axboe
2020-08-29 16:47 ` Jens Axboe
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=20200827074758.GA8009@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=hoeppner@linux.ibm.com \
--cc=josef@toxicpanda.com \
--cc=justin@coraid.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=nbd@other.debian.org \
--cc=sth@linux.ibm.com \
--cc=xianting_tian@126.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.