Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp612907pxb; Tue, 5 Apr 2022 15:59:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJrlA1enI4LRzWC7eRRdOleWOTQfjntX2R27aiJdcOcqDpi4zXIEnP0QIFxZbwaMl3TbR0 X-Received: by 2002:a63:778b:0:b0:398:1568:1c53 with SMTP id s133-20020a63778b000000b0039815681c53mr4651737pgc.548.1649199539711; Tue, 05 Apr 2022 15:58:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649199539; cv=none; d=google.com; s=arc-20160816; b=Xds7h/EOughQRcm27m25S+XKWeUFkoka+gAkXGdaeEhkWWHnqwq4KAJN1LoaqPxSaJ 0DBia7Z8gO/r0DzDIAtTxq/onC0dDh17pemn4OJQBitnozRiFg1eiTmAYLXnN8rAaK0H 0VvUQa2YRQByhC80y7x7ZKXburKmqJOOVY+65GmAIdPBlNJ1RgbZMUcRSEtreW0kQVE+ kwzVafmtNgZ+Hzassuh7Wh1geHLSUgcB8DxPf4nA43G5ZGSxFc7GycA0UiV9G7DgV/81 Isv3IENCa5bWJXt4nfPv8RfdgPNKARgBs0PzOvMpoJ34EcZgphjNfuMm/qIxmYlJAG5A cmCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=CwOCvdXy7T+1Pd7NQ682WAubrpkZiXnHLfiMPtb7OnA=; b=rFOi5cnJ3G6vyeBC6vSOlA4s0/DRLPTZdLMSFga2CtkANX/JtdOqsvJVZOds19/k4N tq3kCsA4vBaDsaKGslfc2bJS9VspRy0Ncz7ZVIy36DEjQLdTa1bME24XHkiykIaTX3WZ 6CrmollJMpdqjgQUF70i7fE9IOioVhNLvM60GGmu8YJgkMEx9BuH8fk0dem5zGQQhrEK rVly7TcXFIepb18aCiAFI8Xug5FLONtvsZnMThXLnbVXgl11hVu8mMysH25wIwKSjmv5 VJlDBpPa3Si3utPrrsGW8VaSp/vhasuwV+L/eh7WAq1dudlZscGNRrjjCrl9l2/y1qHw Rxzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=RwqyLzOA; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id t16-20020a632250000000b003816043f008si14177414pgm.509.2022.04.05.15.58.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Apr 2022 15:58:59 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=RwqyLzOA; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9F242205E0; Tue, 5 Apr 2022 15:40:24 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1388035AbiDENUk (ORCPT + 99 others); Tue, 5 Apr 2022 09:20:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344364AbiDEJTe (ORCPT ); Tue, 5 Apr 2022 05:19:34 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E798254; Tue, 5 Apr 2022 02:07:58 -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 dfw.source.kernel.org (Postfix) with ESMTPS id BFF19614E4; Tue, 5 Apr 2022 09:07:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA97BC385A1; Tue, 5 Apr 2022 09:07:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649149677; bh=K/1JruDGt6uXiQBE2IgAYNU8fm+vGs7kPoKDYyu86Xs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RwqyLzOAj7g0mvsuBOmyVwzSoUqKQ6iNkvtjvwuei6aVuulcIfPvDaNhNC/h4O1vf Ves+ltqaJ0IeNxkA9lwzlW9YmXS+zNy3/lxJD8CjMKDjkspLNWuxjLu5r9Ut7cGu6v 8zQVLJ+5BhuXXXb8U/KNUZJrEZg7iMP69K7Z21Dc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josef Bacik , Anand Jain , David Sterba , Sasha Levin Subject: [PATCH 5.16 0794/1017] btrfs: harden identification of a stale device Date: Tue, 5 Apr 2022 09:28:27 +0200 Message-Id: <20220405070417.820794180@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070354.155796697@linuxfoundation.org> References: <20220405070354.155796697@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Anand Jain [ Upstream commit 770c79fb65506fc7c16459855c3839429f46cb32 ] 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. Reported-by: Josef Bacik Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin --- fs/btrfs/volumes.c | 45 ++++++++++++++++++++++++++++++++++++++------- 1 file changed, 38 insertions(+), 7 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 42391d4aeb11..02ee42d461be 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -530,15 +530,48 @@ btrfs_get_bdev_and_sb(const char *device_path, fmode_t flags, void *holder, return ret; } -static bool device_path_matched(const char *path, struct btrfs_device *device) +/* + * Check if the device in the path matches the device in the given struct device. + * + * Returns: + * true If it is the same device. + * false If it is not the same device or on error. + */ +static bool device_matched(const struct btrfs_device *device, const char *path) { - int found; + char *device_name; + dev_t dev_old; + dev_t dev_new; + int ret; + + /* + * If we are looking for a device with the matching dev_t, then skip + * device without a name (a missing device). + */ + if (!device->name) + return false; + + device_name = kzalloc(BTRFS_PATH_NAME_MAX, GFP_KERNEL); + if (!device_name) + return false; rcu_read_lock(); - found = strcmp(rcu_str_deref(device->name), path); + scnprintf(device_name, BTRFS_PATH_NAME_MAX, "%s", rcu_str_deref(device->name)); rcu_read_unlock(); - return found == 0; + ret = lookup_bdev(device_name, &dev_old); + kfree(device_name); + if (ret) + return false; + + ret = lookup_bdev(path, &dev_new); + if (ret) + return false; + + if (dev_old == dev_new) + return true; + + return false; } /* @@ -571,9 +604,7 @@ static int btrfs_free_stale_devices(const char *path, &fs_devices->devices, dev_list) { if (skip_device && skip_device == device) continue; - if (path && !device->name) - continue; - if (path && !device_path_matched(path, device)) + if (path && !device_matched(device, path)) continue; if (fs_devices->opened) { /* for an already deleted device return 0 */ -- 2.34.1