Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2255413imm; Thu, 7 Jun 2018 07:47:14 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLSzzU+EUMjJr64iOCK7ofxPtevJ1krFR/fNW9renvj/BkE/oq/3d+/2mWIZSa65aKgK159 X-Received: by 2002:a17:902:5ac8:: with SMTP id g8-v6mr2312726plm.221.1528382834015; Thu, 07 Jun 2018 07:47:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528382833; cv=none; d=google.com; s=arc-20160816; b=Ui+zw9SSB87ASmPqrUOnIo9pmXU1t1qXO4ASGeVCwgICRBRESVXfc3aDWxAsjEdu8T +cfcG0+xhc3CEzSjylfMrlt2zK1blACcZfsbXfOxE1u8cgqn7oVG6tHBblRX9etwdaz+ dhhtqo7m2TfldiG+oj6wfkHYGpL8lsHuaLHP1D4PjHFxiyFjh29LxwdVIcJzGXCG/PZG 1XxLZk0l55sIivCfxOSz3R11dGFsTbzsuzD5iPbyITXS4L4Pez8S5wKBOOvURQWOVIdK wWy6dmq8393WZhE2f8YZKeT197AO5310aFZMBGG7MHDNBy6tIVvC/44CD1PlDBsU6Vby kTlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=ZrYIvJB96gWIK2nb114Z6sg3y2vbVkSWZ/8Xvf3Xp9o=; b=caEmVbv0x/IOxstPMGdMmA0ID+c5DX7HAWHF90moukBC9Jk5DRoxmqvRtzWgbAOJA0 8jWBwytDf89b6txX7+AAEZCIZ0iRWS9s0W/U4RCg47DkBHvyXXVdmlMYv80wfZb7sadD eeWC+X4v713Rzyft3XXmIWOdn6mjppbjK+BqUz/oXTFwj+hxrOO5EEuGNCK1DA1FgSYA EeqmSnp7wrPR/ruUur1DTccSXx4IbP5gsu5WPwhB0xy0+gHDXS3ivpeVag7V4ZRTpppT YKNHCqXWWjTCP+RsP1YLQXXqMuDK7XtqIxpQ8cdM5OPHT/+v0fmkrKNlDVhbIfKdR9WS WpgQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v16-v6si51333352pfm.151.2018.06.07.07.46.59; Thu, 07 Jun 2018 07:47:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934976AbeFGOqH (ORCPT + 99 others); Thu, 7 Jun 2018 10:46:07 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:40750 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934566AbeFGOqD (ORCPT ); Thu, 7 Jun 2018 10:46:03 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvbT-0005Zj-LR; Thu, 07 Jun 2018 15:09:28 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvbB-0003BX-IR; Thu, 07 Jun 2018 15:09:09 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Jens Axboe" , "Michael Lyle" , "Tang Junhui" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 323/410] bcache: don't attach backing with duplicate UUID In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Michael Lyle commit 86755b7a96faed57f910f9e6b8061e019ac1ec08 upstream. 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 Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings --- drivers/md/bcache/super.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -964,6 +964,7 @@ int bch_cached_dev_attach(struct cached_ 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_ 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 &&