Received: by 10.192.165.148 with SMTP id m20csp530915imm; Wed, 25 Apr 2018 03:46:39 -0700 (PDT) X-Google-Smtp-Source: AIpwx48PA/LL5s6ba3Z5TvdfhwOBiTstpbEG1weVe/pgyq/6j/vcIYCeJUyKKKtwH9f80UorE53C X-Received: by 10.98.210.134 with SMTP id c128mr23612569pfg.240.1524653199663; Wed, 25 Apr 2018 03:46:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524653199; cv=none; d=google.com; s=arc-20160816; b=EL4H4XbNsdDpuodIAloEK0T2CtzjjzdDI1cjSXJUnTzWSl/HOdQCW5bUgEdAM+eaik tKpWFbE5uQhpHeA467K2Rhh6lY0jJD3Eqbsh0a0aly50gBXe2MPP8/zdUmHHqhHsgDyG g7OrG4+cd+mtp3Q+RFY5KUCBF9+Kjfr1yTLtZdrHGEhVbabLj4fzDHAnUcf8eCN+6FI0 Q7IpoQzgSurrFQcqkA3yb5toYplBYR0QneRJjTgyKFgbyp0r1jJkHbxHwXx/ar2GThL2 K6yf/mrFXsozequpeifGQB2mruWjAhQEDTRyoerotquPo+Z8JlyWsM7DVcYtD7RIX//Z UBuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=iqmosItVENiu+6VprPjNMTXTZhD3yhSg5/pOW+Pb/O4=; b=oowZnoI1wJL93bzHxBUN/j8WoVEuVRB36mTEG3qA/FOPA8PS+KX/EwcYy8joh6m1gm HLIvMk7g5Do2SwmqZDWmTEvEVdXLrHirH1nddt9hPxW0Sww5YquXIbPtKVkTcAoA+PQu vxfaGcz7u1fW7Uv/hb7Uw2KKdBRbL7kbwjC2IBA31K+4+V3HDONm9MAY52auyDszoStb TFcoegAz+q7VxzspfvdWmi3M5UeEOOoFpX3xvbc3+MdhyRKDxDIzTYCvOnN8l5pp0mT1 H2Q7eRIIhEEBLdW8soBpBirH05BSTNvSPILu1HU84UVsOK7i4jga+FuoS5TONOtQnO7j i35Q== 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 m72si15541704pfi.236.2018.04.25.03.46.25; Wed, 25 Apr 2018 03:46:39 -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 S1754201AbeDYKpM (ORCPT + 99 others); Wed, 25 Apr 2018 06:45:12 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:53488 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754034AbeDYKpF (ORCPT ); Wed, 25 Apr 2018 06:45:05 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id E156841C; Wed, 25 Apr 2018 10:45:03 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tang Junhui , Michael Lyle , Jens Axboe , Sasha Levin Subject: [PATCH 4.14 149/183] bcache: fix for data collapse after re-attaching an attached device Date: Wed, 25 Apr 2018 12:36:09 +0200 Message-Id: <20180425103248.522789608@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180425103242.532713678@linuxfoundation.org> References: <20180425103242.532713678@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tang Junhui [ Upstream commit 73ac105be390c1de42a2f21643c9778a5e002930 ] back-end device sdm has already attached a cache_set with ID f67ebe1f-f8bc-4d73-bfe5-9dc88607f119, then try to attach with another cache set, and it returns with an error: [root]# cd /sys/block/sdm/bcache [root]# echo 5ccd0a63-148e-48b8-afa2-aca9cbd6279f > attach -bash: echo: write error: Invalid argument After that, execute a command to modify the label of bcache device: [root]# echo data_disk1 > label Then we reboot the system, when the system power on, the back-end device can not attach to cache_set, a messages show in the log: Feb 5 12:05:52 ceph152 kernel: [922385.508498] bcache: bch_cached_dev_attach() couldn't find uuid for sdm in set In sysfs_attach(), dc->sb.set_uuid was assigned to the value which input through sysfs, no matter whether it is success or not in bch_cached_dev_attach(). For example, If the back-end device has already attached to an cache set, bch_cached_dev_attach() would fail, but dc->sb.set_uuid was changed. Then modify the label of bcache device, it will call bch_write_bdev_super(), which would write the dc->sb.set_uuid to the super block, so we record a wrong cache set ID in the super block, after the system reboot, the cache set couldn't find the uuid of the back-end device, so the bcache device couldn't exist and use any more. In this patch, we don't assigned cache set ID to dc->sb.set_uuid in sysfs_attach() directly, but input it into bch_cached_dev_attach(), and assigned dc->sb.set_uuid to the cache set ID after the back-end device attached to the cache set successful. Signed-off-by: Tang Junhui Reviewed-by: Michael Lyle Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/md/bcache/bcache.h | 2 +- drivers/md/bcache/super.c | 10 ++++++---- drivers/md/bcache/sysfs.c | 6 ++++-- 3 files changed, 11 insertions(+), 7 deletions(-) --- a/drivers/md/bcache/bcache.h +++ b/drivers/md/bcache/bcache.h @@ -906,7 +906,7 @@ void bcache_write_super(struct cache_set int bch_flash_dev_create(struct cache_set *c, uint64_t size); -int bch_cached_dev_attach(struct cached_dev *, struct cache_set *); +int bch_cached_dev_attach(struct cached_dev *, struct cache_set *, uint8_t *); void bch_cached_dev_detach(struct cached_dev *); void bch_cached_dev_run(struct cached_dev *); void bcache_device_stop(struct bcache_device *); --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -939,7 +939,8 @@ void bch_cached_dev_detach(struct cached cached_dev_put(dc); } -int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c) +int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c, + uint8_t *set_uuid) { uint32_t rtime = cpu_to_le32(get_seconds()); struct uuid_entry *u; @@ -948,7 +949,8 @@ int bch_cached_dev_attach(struct cached_ bdevname(dc->bdev, buf); - if (memcmp(dc->sb.set_uuid, c->sb.set_uuid, 16)) + if ((set_uuid && memcmp(set_uuid, c->sb.set_uuid, 16)) || + (!set_uuid && memcmp(dc->sb.set_uuid, c->sb.set_uuid, 16))) return -ENOENT; if (dc->disk.c) { @@ -1190,7 +1192,7 @@ static void register_bdev(struct cache_s list_add(&dc->list, &uncached_devices); list_for_each_entry(c, &bch_cache_sets, list) - bch_cached_dev_attach(dc, c); + bch_cached_dev_attach(dc, c, NULL); if (BDEV_STATE(&dc->sb) == BDEV_STATE_NONE || BDEV_STATE(&dc->sb) == BDEV_STATE_STALE) @@ -1712,7 +1714,7 @@ static void run_cache_set(struct cache_s bcache_write_super(c); list_for_each_entry_safe(dc, t, &uncached_devices, list) - bch_cached_dev_attach(dc, c); + bch_cached_dev_attach(dc, c, NULL); flash_devs_run(c); --- a/drivers/md/bcache/sysfs.c +++ b/drivers/md/bcache/sysfs.c @@ -265,11 +265,13 @@ STORE(__cached_dev) } if (attr == &sysfs_attach) { - if (bch_parse_uuid(buf, dc->sb.set_uuid) < 16) + uint8_t set_uuid[16]; + + if (bch_parse_uuid(buf, set_uuid) < 16) return -EINVAL; list_for_each_entry(c, &bch_cache_sets, list) { - v = bch_cached_dev_attach(dc, c); + v = bch_cached_dev_attach(dc, c, set_uuid); if (!v) return size; }