Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 7 Jul 2020 22:29:35 -0400
From:   Sasha Levin <sashal@kernel.org>
To:     Pavel Machek <pavel@denx.de>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Anton Eidelman <anton@lightbitslabs.com>,
        Sagi Grimberg <sagi@grimberg.me>,
        Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 4.19 10/36] nvme: fix possible deadlock when I/O is
 blocked
Message-ID: <20200708022935.GW2722994@sasha-vm>
References: <20200707145749.130272978@linuxfoundation.org>
 <20200707145749.639245963@linuxfoundation.org>
 <20200707181641.GA6290@amd>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20200707181641.GA6290@amd>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Jul 07, 2020 at 08:16:41PM +0200, Pavel Machek wrote:
>Hi!
>
>> From: Sagi Grimberg <sagi@grimberg.me>
>>
>> [ Upstream commit 3b4b19721ec652ad2c4fe51dfbe5124212b5f581 ]
>>
>> Revert fab7772bfbcf ("nvme-multipath: revalidate nvme_ns_head gendisk
>> in nvme_validate_ns")
>>
>> When adding a new namespace to the head disk (via nvme_mpath_set_live)
>> we will see partition scan which triggers I/O on the mpath device node.
>> This process will usually be triggered from the scan_work which holds
>> the scan_lock. If I/O blocks (if we got ana change currently have only
>> available paths but none are accessible) this can deadlock on the head
>> disk bd_mutex as both partition scan I/O takes it, and head disk revalidation
>> takes it to check for resize (also triggered from scan_work on a different
>> path). See trace [1].
>>
>> The mpath disk revalidation was originally added to detect online disk
>> size change, but this is no longer needed since commit cb224c3af4df
>> ("nvme: Convert to use set_capacity_revalidate_and_notify") which
>> already
>
>AFAICT cb224c3af4df is not applied to 4.19-stable series, so this is
>not safe according to the changelog.
>
>cb224c3af4df is simple enough, but AFAICT
>set_capacity_revalidate_and_notify() is missing in 4.19.132-rc1.

Good point... It might be the case that e598a72faeb5 ("block/genhd:
Notify udev about capacity change") is safe to take along with
cb224c3af4df.

I'll look at it once these releases are out, but for now I'll drop this
commit. Thanks!

-- 
Thanks,
Sasha