From patchwork Tue Jul 25 01:11:28 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shawn Lin X-Patchwork-Id: 9860939 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 3BD3760385 for ; Tue, 25 Jul 2017 01:12:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 247F5283BF for ; Tue, 25 Jul 2017 01:12:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 175B62858E; Tue, 25 Jul 2017 01:12:15 +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.4 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM 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 A7F9A283BF for ; Tue, 25 Jul 2017 01:12:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753565AbdGYBMN (ORCPT ); Mon, 24 Jul 2017 21:12:13 -0400 Received: from lucky1.263xmail.com ([211.157.147.134]:34878 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753510AbdGYBMM (ORCPT ); Mon, 24 Jul 2017 21:12:12 -0400 Received: from shawn.lin?rock-chips.com (unknown [192.168.167.154]) by lucky1.263xmail.com (Postfix) with ESMTP id 8B0C2C8E; Tue, 25 Jul 2017 09:12:08 +0800 (CST) X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 Received: from localhost.localdomain (localhost [127.0.0.1]) by smtp.263.net (Postfix) with ESMTPA id 67D41375; Tue, 25 Jul 2017 09:12:03 +0800 (CST) X-RL-SENDER: shawn.lin@rock-chips.com X-FST-TO: ulf.hansson@linaro.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: shawn.lin@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-SENDER: lintao@rock-chips.com X-DNS-TYPE: 0 Received: from localhost.localdomain (unknown [58.22.7.114]) by smtp.263.net (Postfix) whith ESMTP id 21273SAVVMF; Tue, 25 Jul 2017 09:12:04 +0800 (CST) From: Shawn Lin To: Ulf Hansson Cc: linux-mmc@vger.kernel.org, Linus Walleij , Grzegorz Sluja , Shawn Lin , stable@vger.kernel.org Subject: [PATCH] mmc: block: bypass the queue even if usage is present for hotplug Date: Tue, 25 Jul 2017 09:11:28 +0800 Message-Id: <1500945088-202242-1-git-send-email-shawn.lin@rock-chips.com> X-Mailer: git-send-email 1.9.1 Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP commit 304419d8a7e ("mmc: core: Allocate per-request data using the block layer core") refactored mechanism of queue handling caused mmc_init_request() can be called just after mmc_cleanup_queue() caused null pointer dereference. commit bbdc74dc19e09a ("mmc: block: Prevent new req entering queue after its cleanup")tried to fix the problem. However it actually miss one corner case. We could still reproduce the issue mentioned with these steps: (1) insert a SD card and mount it (2) hotplug it, so it will leave md->usage still be counted (3) reboot the system which will sync data and umount the card [Unable to handle kernel NULL pointer dereference at virtual address 00000000 [user pgtable: 4k pages, 48-bit VAs, pgd = ffff80007bab3000 [[0000000000000000] *pgd=000000007a828003, *pud=0000000078dce003, *pmd=000000007aab6003, *pte=0000000000000000 [Internal error: Oops: 96000007 [#1] PREEMPT SMP [Modules linked in: [CPU: 3 PID: 3507 Comm: umount Tainted: G W 4.13.0-rc1-next-20170720-00012-g9d9bf45 #33 [Hardware name: Firefly-RK3399 Board (DT) [task: ffff80007a1de200 task.stack: ffff80007a01c000 [PC is at mmc_init_request+0x14/0xc4 [LR is at alloc_request_size+0x4c/0x74 [pc : [] lr : [] pstate: 600001c5 [sp : ffff80007a01f8f0 .... [[] mmc_init_request+0x14/0xc4 [[] alloc_request_size+0x4c/0x74 [[] mempool_create_node+0xb8/0x17c [[] blk_init_rl+0x9c/0x120 [[] blkg_alloc+0x110/0x234 [[] blkg_create+0x424/0x468 [[] blkg_lookup_create+0xd8/0x14c [[] generic_make_request_checks+0x368/0x3b0 [[] generic_make_request+0x1c/0x240 So mmc_blk_put wouldn't calling blk_cleanup_queue which actually the QUEUE_FLAG_DYING and QUEUE_FLAG_BYPASS should stay. Block core expect blk_queue_bypass_{start, end} internally to bypass/drain the queue before actually dying the queue, so it didn't expose API to set the queue bypass. I think we should set QUEUE_FLAG_BYPASS whenever queue is removed, although the md->usage is still counted, as no dispatch queue could be found then. commit 304419d8a7e9 ("mmc: core: Allocate per-request data using the block layer core") Cc: stable@vger.kernel.org Signed-off-by: Shawn Lin Reviewed-by: Linus Walleij --- drivers/mmc/core/block.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index 40f0d59..a11bead 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -2168,6 +2168,7 @@ static void mmc_blk_remove_req(struct mmc_blk_data *md) * from being accepted. */ card = md->queue.card; + queue_flag_set(QUEUE_FLAG_BYPASS, md->queue.queue); blk_set_queue_dying(md->queue.queue); mmc_cleanup_queue(&md->queue); if (md->disk->flags & GENHD_FL_UP) {