From patchwork Mon Mar 5 21:41:55 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Lyle X-Patchwork-Id: 10259941 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 3D2BE60134 for ; Mon, 5 Mar 2018 21:42:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2C48A28C9B for ; Mon, 5 Mar 2018 21:42:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 20BC328C9D; Mon, 5 Mar 2018 21:42:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4E12A28CA6 for ; Mon, 5 Mar 2018 21:42:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932760AbeCEVmK (ORCPT ); Mon, 5 Mar 2018 16:42:10 -0500 Received: from mail-pg0-f68.google.com ([74.125.83.68]:39079 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752941AbeCEVmG (ORCPT ); Mon, 5 Mar 2018 16:42:06 -0500 Received: by mail-pg0-f68.google.com with SMTP id e3so2711455pga.6 for ; Mon, 05 Mar 2018 13:42:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lyle-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=OwBYFC0HvUN9SIGjAgn+uogpsVuarjIkC+mYWzzaNzY=; b=l9lF45Hl/kojdVRax74y+yfWvyk+e4P3C4zw0zVjQGL4HpnapY4Ot8MLkVRfK3VCTS EVuNOBBIy2LCQBOwnGj4ZXEs3nv2b1wLzjMGeu6nrl/e565I6YxGJ+XlB4eNy3ZsN/7/ d89C5UM7QTsbHEYs6uNBU1rUFRzDiGohLgWHlm4TRFqv4IYurFtgv++L3Oep8eC1RMq0 Gx/aGiXaM7VRK/w52GFA5Gf/nyMkDNOWvkJCNGePPw9zeOd2pJPoPuRKR8+PM6f2DHvK v/ocf64ZDh8zdlwLvajFBZVER564hkxZupjktW3k/K1DLRq9UjL4YiQEr0j21Z37Ki8T 5oiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=OwBYFC0HvUN9SIGjAgn+uogpsVuarjIkC+mYWzzaNzY=; b=rfrrBDCQCHJCmh0QOEaGED5ysp+dUTqicZTJpVj2O5+pwvj0XZnFDZMAoguE/8khJD kSBwqGSTKsCjl3DLo4Z0fOk1SW4TPjDSxUd/mG1R+H8oGsLww2YIGavCgFKLDOZQr4Es yrV9+aoOivZA4lVzxm8mMQPqGb2qdPfcwrrX48CfjakBh8qCQ1TjgzHaJKBx4yEIKlC/ tSVZHi14BJH2i7SlY0L0lls+drCtSCN3hxnCV/Q2Bapf9Yi/+OULN8P2AmoyowDPlIA9 yA4SWOvZL/WZitfDRnffFyUF2yTjzHzy2po9hOdroCSGaEWiv6Yvc/pPOljNE2CJiRS2 ayTw== X-Gm-Message-State: AElRT7HSJQbKlDFhOESuI75VZej46T5zT45nhT7Fg5L9+rGcZ1rqU9Ge WCGJqpd/yGRFa+GqNwIhh3mpRyhb X-Google-Smtp-Source: AG47ELttN7hxJdvKJTf4JZMXssqc2byZpfJtOFoQzl4NCcfgUIEGnbUsr95cs/5Saj3VnirULqBIKQ== X-Received: by 10.98.189.24 with SMTP id a24mr11621892pff.125.1520286125719; Mon, 05 Mar 2018 13:42:05 -0800 (PST) Received: from midnight.lan (2600-6c52-6200-09b7-0000-0000-0000-0d66.dhcp6.chtrptr.net. [2600:6c52:6200:9b7::d66]) by smtp.gmail.com with ESMTPSA id f82sm32314211pfd.175.2018.03.05.13.42.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Mar 2018 13:42:05 -0800 (PST) From: Michael Lyle To: linux-block@vger.kernel.org, linux-bcache@vger.kernel.org Cc: axboe@kernel.dk, Michael Lyle , stable@vger.kernel.org Subject: [PATCH 2/2] bcache: don't attach backing with duplicate UUID Date: Mon, 5 Mar 2018 13:41:55 -0800 Message-Id: <20180305214155.23395-3-mlyle@lyle.org> X-Mailer: git-send-email 2.14.1 In-Reply-To: <20180305214155.23395-1-mlyle@lyle.org> References: <20180305214155.23395-1-mlyle@lyle.org> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This can happen e.g. during disk cloning. This is an incomplete fix: it does not catch duplicate UUIDs earlier when things are still unattached. It does not unregister the device. Further changes to cope better with this are planned but conflict with Coly's ongoing improvements to handling device errors. In the meantime, one can manually stop the device after this has happened. Attempts to attach a duplicate device result in: [ 136.372404] loop: module loaded [ 136.424461] bcache: register_bdev() registered backing device loop0 [ 136.424464] bcache: bch_cached_dev_attach() Tried to attach loop0 but duplicate UUID already attached My test procedure is: dd if=/dev/sdb1 of=imgfile bs=1024 count=262144 losetup -f imgfile Signed-off-by: Michael Lyle Reviewed-by: Tang Junhui Cc: --- drivers/md/bcache/super.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c index 9c141a8aaacc..5cace6892958 100644 --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -963,6 +963,7 @@ int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c, uint32_t rtime = cpu_to_le32(get_seconds()); struct uuid_entry *u; char buf[BDEVNAME_SIZE]; + struct cached_dev *exist_dc, *t; bdevname(dc->bdev, buf); @@ -987,6 +988,16 @@ int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c, return -EINVAL; } + /* Check whether already attached */ + list_for_each_entry_safe(exist_dc, t, &c->cached_devs, list) { + if (!memcmp(dc->sb.uuid, exist_dc->sb.uuid, 16)) { + pr_err("Tried to attach %s but duplicate UUID already attached", + buf); + + return -EINVAL; + } + } + u = uuid_find(c, dc->sb.uuid); if (u &&