From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D666C3A5A7 for ; Tue, 6 Dec 2022 08:48:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B20828E0002; Tue, 6 Dec 2022 03:48:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AD0B78E0001; Tue, 6 Dec 2022 03:48:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9972E8E0002; Tue, 6 Dec 2022 03:48:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 894468E0001 for ; Tue, 6 Dec 2022 03:48:50 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5EFDF1C6573 for ; Tue, 6 Dec 2022 08:48:50 +0000 (UTC) X-FDA: 80211256020.02.1E56960 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf30.hostedemail.com (Postfix) with ESMTP id 9B2EF80011 for ; Tue, 6 Dec 2022 08:48:48 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of zhongjinghua@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=zhongjinghua@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670316529; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=6cQcJI2Oi/rTtc12lLfQW3G92OVbPXC3Mi0U4uLBYE4=; b=k2AlS7cuPX96IBu8z0f2fNeS+7u6hYKF7kuG8Zev0CJZRE+rEpkneR3vcRd9WLnAmo/dy4 ioIR5alFxWSxc5eJLLQklt4/w86WaY+UwREwWM8Qcmf39pPBy2S2XhILIvO9duLQ5rS0xJ CnX6Z7uCgz5mXntTpLD+xJxkjjy5LIw= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of zhongjinghua@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=zhongjinghua@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670316529; a=rsa-sha256; cv=none; b=nI6XEvwoKRaoP1mx4kW24/Gt9xsAMs14GjDBmwg66x5D8siB3T1FRVa+q986W/KyzDQZyF uQlQDIQeMEgJfmWxbVzTEauz8N2hvm1WScm89mQOH2Rwy62cD54pjYzadsvelMuFU803EC aBXbh3JGPijdZf0f7S2r65xQ0lQNGzQ= Received: from kwepemm600002.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4NRDVp17v9zqSvj; Tue, 6 Dec 2022 16:44:34 +0800 (CST) Received: from localhost.localdomain (10.175.127.227) by kwepemm600002.china.huawei.com (7.193.23.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 6 Dec 2022 16:48:42 +0800 From: Zhong Jinghua To: , , CC: , , , , Subject: [PATCH-next] block: fix null-deref in percpu_ref_put Date: Tue, 6 Dec 2022 17:09:39 +0800 Message-ID: <20221206090939.871239-1-zhongjinghua@huawei.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600002.china.huawei.com (7.193.23.29) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9B2EF80011 X-Rspam-User: X-Stat-Signature: co1ehwxs3chy75cmbuo6pkp8rd3xq94u X-Spamd-Result: default: False [-2.20 / 9.00]; BAYES_HAM(-6.00)[99.99%]; R_MISSING_CHARSET(2.50)[]; MID_CONTAINS_FROM(1.00)[]; SUBJECT_HAS_UNDERSCORES(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[huawei.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:45.249.212.187/29]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_SEVEN(0.00)[8]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; HAS_XOIP(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[] X-HE-Tag: 1670316528-830998 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: A problem was find in stable 5.10 and the root cause of it like below. In the use of q_usage_counter of request_queue, blk_cleanup_queue using "wait_event(q->mq_freeze_wq, percpu_ref_is_zero(&q->q_usage_counter))" to wait q_usage_counter becoming zero. however, if the q_usage_counter becoming zero quickly, and percpu_ref_exit will execute and ref->data will be freed, maybe another process will cause a null-defef problem like below: CPU0 CPU1 blk_mq_destroy_queue blk_freeze_queue blk_mq_freeze_queue_wait scsi_end_request percpu_ref_get ... percpu_ref_put atomic_long_sub_and_test blk_put_queue kobject_put kref_put blk_release_queue percpu_ref_exit ref->data -> NULL ref->data->release(ref) -> null-deref As suggested by Ming Lei, fix it by getting the release method before the referebce count is minus 0. Suggested-by: Ming Lei Signed-off-by: Zhong Jinghua --- include/linux/percpu-refcount.h | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h index d73a1c08c3e3..11e717c95acb 100644 --- a/include/linux/percpu-refcount.h +++ b/include/linux/percpu-refcount.h @@ -331,8 +331,11 @@ static inline void percpu_ref_put_many(struct percpu_ref *ref, unsigned long nr) if (__ref_is_percpu(ref, &percpu_count)) this_cpu_sub(*percpu_count, nr); - else if (unlikely(atomic_long_sub_and_test(nr, &ref->data->count))) - ref->data->release(ref); + else { + percpu_ref_func_t *release = ref->data->release; + if (unlikely(atomic_long_sub_and_test(nr, &ref->data->count))) + release(ref); + } rcu_read_unlock(); } -- 2.31.1