From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stable-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 9A056C54EE9
	for <stable@archiver.kernel.org>; Fri,  2 Sep 2022 09:23:29 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S235293AbiIBJX2 (ORCPT <rfc822;stable@archiver.kernel.org>);
        Fri, 2 Sep 2022 05:23:28 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57172 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S235177AbiIBJX0 (ORCPT
        <rfc822;stable@vger.kernel.org>); Fri, 2 Sep 2022 05:23:26 -0400
Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00E7EC6E9B;
        Fri,  2 Sep 2022 02:23:25 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by ams.source.kernel.org (Postfix) with ESMTPS id AAC55B82A57;
        Fri,  2 Sep 2022 09:23:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE586C433D7;
        Fri,  2 Sep 2022 09:23:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
        s=korg; t=1662110603;
        bh=6NWXZKd0rnugZS+klAYys9nN2J10LtCxssc2yGCNKmA=;
        h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
        b=e0KnBlSn6IA28mbWOPaxjCXGBbI1pD18lxIfqKG/yd4y39ngRNtIWI2/bckPihyFa
         rPqXOgvyNckxpVrolwbyiaRlRju0MiLVfuMqMY/Z3NxZZ38QgmCMOEzxUUC/OQDHST
         YlVBieEQYwKTU5AOyAo2KFoyke9lTgTwqnRiIyaA=
Date:   Fri, 2 Sep 2022 11:23:20 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Anand Jain <anand.jain@oracle.com>
Cc:     stable@vger.kernel.org, linux-btrfs@vger.kernel.org,
        Josef Bacik <josef@toxicpanda.com>,
        David Sterba <dsterba@suse.com>
Subject: Re: [PATCH STABLE 5.4] btrfs: harden identification of a stale device
Message-ID: <YxHLiLPd0IfKrpT5@kroah.com>
References: <73979e98c7edc6690959f1d5e9e8d2bb678a8101.1661473186.git.anand.jain@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <73979e98c7edc6690959f1d5e9e8d2bb678a8101.1661473186.git.anand.jain@oracle.com>
Precedence: bulk
List-ID: <stable.vger.kernel.org>
X-Mailing-List: stable@vger.kernel.org

On Fri, Sep 02, 2022 at 05:09:38PM +0800, Anand Jain wrote:
> commit 770c79fb65506fc7c16459855c3839429f46cb32 upstream
> 
> Identifying and removing the stale device from the fs_uuids list is done
> by btrfs_free_stale_devices().  btrfs_free_stale_devices() in turn
> depends on device_path_matched() to check if the device appears in more
> than one btrfs_device structure.
> 
> The matching of the device happens by its path, the device path. However,
> when device mapper is in use, the dm device paths are nothing but a link
> to the actual block device, which leads to the device_path_matched()
> failing to match.
> 
> Fix this by matching the dev_t as provided by lookup_bdev() instead of
> plain string compare of the device paths.
> 
> CC: stable@vger.kernel.org #5.4
> Reported-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Anand Jain <anand.jain@oracle.com>
> Signed-off-by: David Sterba <dsterba@suse.com>
> ---
>  fs/btrfs/volumes.c | 44 +++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 37 insertions(+), 7 deletions(-)

What about the same change for 5.10.y?

thanks,

greg k-h