Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2974502imu; Sun, 9 Dec 2018 14:04:08 -0800 (PST) X-Google-Smtp-Source: AFSGD/X/9pofekKAnGS+JpiPA/S6KDm5aPb3zFsWg1/N27KCVmliMo1gbWukuQP3bToA24v/XnNS X-Received: by 2002:a62:3c1:: with SMTP id 184mr10175906pfd.56.1544393047958; Sun, 09 Dec 2018 14:04:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544393047; cv=none; d=google.com; s=arc-20160816; b=vbdA5Q+1jY9ie5SCCXu1uNb/+bTYjRuqLmXR0ouLUDOoObKjbJU0pjg5Hm/fx5MyhV VeR9Tt2ZAboOty+SMDuRJcLWKXYkzEl5hrE2yAn5SQxisp73/8jM76A3c7RCwd0blfXu g6Zcxo3uW2k451CuRnATJ6nqX1AgnysQbTOPvgit3W+kckU2l55js4W2We7sqk9rXr0j i+ZYGNDqHRusovVeU5JuLGs0KzyKN5ndMP5Y+8iRqm7CWe6gEN2xUX1ilTIbJWQzs/u5 SMes4O8AZJy5mjIndKqJl6ZiSIj0Sl3b+BJjIQqDTvLkEZOetcJaSdpCCW1E3CMo/S8L ZziA== 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; bh=pnpbWZKwel+YGi4UMQ9En9g9eGOXKttM5CXBaUHSBxo=; b=AhYQeyxCcUT05jiFu/elTOGX6xFGWmPoe7p9pTtC7d42xG4triRgDXTEg3OrCScVfV 2r9o06gigPo1/uAWDfgRxJiQ9wyYDhlg1EhJZhC9S3/ly/UduVKyubLxmlcJnJsmo5yg 1GhVS/fEM3s+16j9VsUQYltqoyrR1auedPuM/WRYb5gfb1UD64CQaKr7rYByDfn6SiSx iS5yG6cYcoXkkzuXA5i6JOOXnesgedrDZg2oQydJ3eNJMOjCGt6RVib4SmwWZGAdeAA3 8VyyzcLiAj5VOJkT+c6P4+RyRkawcq4R+4WSdx2b7W0gyneB5QNEP7Xozz1aP581ajKe 5alw== 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 o6si8550152plh.23.2018.12.09.14.03.52; Sun, 09 Dec 2018 14:04:07 -0800 (PST) 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 S1727128AbeLIWB1 (ORCPT + 99 others); Sun, 9 Dec 2018 17:01:27 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35956 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726678AbeLIVze (ORCPT ); Sun, 9 Dec 2018 16:55:34 -0500 Received: from pub.yeoldevic.com ([81.174.156.145] helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gW72w-0002ij-VT; Sun, 09 Dec 2018 21:55:31 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gW72j-0003bm-Bq; Sun, 09 Dec 2018 21:55:17 +0000 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, "Michael Lyle" , "Eric Wheeler" , "Jens Axboe" , "Coly Li" , "Liang Chen" Date: Sun, 09 Dec 2018 21:50:33 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 267/328] bcache: explicitly destroy mutex while exiting In-Reply-To: X-SA-Exim-Connect-IP: 81.174.156.145 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.62-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Liang Chen commit 330a4db89d39a6b43f36da16824eaa7a7509d34d upstream. mutex_destroy does nothing most of time, but it's better to call it to make the code future proof and it also has some meaning for like mutex debug. As Coly pointed out in a previous review, bcache_exit() may not be able to handle all the references properly if userspace registers cache and backing devices right before bch_debug_init runs and bch_debug_init failes later. So not exposing userspace interface until everything is ready to avoid that issue. Signed-off-by: Liang Chen Reviewed-by: Michael Lyle Reviewed-by: Coly Li Reviewed-by: Eric Wheeler Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings --- drivers/md/bcache/super.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -2115,6 +2115,7 @@ static void bcache_exit(void) if (bcache_major) unregister_blkdev(bcache_major, "bcache"); unregister_reboot_notifier(&reboot); + mutex_destroy(&bch_register_lock); } static int __init bcache_init(void) @@ -2133,14 +2134,15 @@ static int __init bcache_init(void) bcache_major = register_blkdev(0, "bcache"); if (bcache_major < 0) { unregister_reboot_notifier(&reboot); + mutex_destroy(&bch_register_lock); return bcache_major; } if (!(bcache_wq = alloc_workqueue("bcache", WQ_MEM_RECLAIM, 0)) || !(bcache_kobj = kobject_create_and_add("bcache", fs_kobj)) || - sysfs_create_files(bcache_kobj, files) || bch_request_init() || - bch_debug_init(bcache_kobj)) + bch_debug_init(bcache_kobj) || + sysfs_create_files(bcache_kobj, files)) goto err; return 0;