Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp438414ybl; Thu, 23 Jan 2020 01:19:36 -0800 (PST) X-Google-Smtp-Source: APXvYqxVqDJICqjFR1Turm+MkMPiQRCiqmmgrW4GHldKunLVHISKpoGT/9jFO4glDQPBNwhwgvVh X-Received: by 2002:a9d:3f61:: with SMTP id m88mr10258326otc.56.1579771176438; Thu, 23 Jan 2020 01:19:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579771176; cv=none; d=google.com; s=arc-20160816; b=M7pN2x+HiLMsrGEQUemuP1x3myH2XxOz5pxTGWH9Tfv6Zw9lZQt20kfzGUG4J4RLSA /fwZbe+dJrCpeJeaHSOukDuiaBECwR08HujNPobUOZ6ibdrURJWitmnUw7Qu74F87t/2 W8I/5BFC8rfXrjprqDb8BQuHU+VIInKvPkPiKQqIJqeakxVPJY1cCEOA9agG1xlk9pss LioPP+Y9JLWbH271bR9WKH6Ws5HrmTWRGEDg9hhJuf3kf1cDk+ml7rWnmmocuRl4eepm KRiLYpS2HQKlSlAWD0Aq2r1WyQAeFXGoHj2qUnk22skadgJXCbkCGuDM1I7z/mKTrMda LsuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=wCUnI1IM3O9kONq0sBE+EnDaG81vpDpYxVKmGdgTFJA=; b=vh0PKJEf37Z0AX9omXii509KUPOppZl/mcD4hf3N2s2foPalW5w04P+rnlyWbedJAs km6B5Dm+BAAjLnC4I3+L/BYZ9m1tPGXOCiZs0HEio1N3p2xAhYyMh3aa2YRpt/J1ZlLs 9xzl3AfoJGbHX496AJ1Ny4PcSbJUbnbf55bIRNH0k5aAGayulYnBouorB0jiJC97AO5z ZCJclYjRlRO0xU4rZd7ofWs1OcnLpAQfe582yEFjtig+ZmyJl2AfTWmGTjFn6L409bdZ +fiwl1sXApRiaiW/c+5O1HKY/rUAaDHEEjmGGC3bUOfQmpJvyzNBrtZpPmvHlyCRtUhU MEQg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y8si823262otg.309.2020.01.23.01.19.24; Thu, 23 Jan 2020 01:19:36 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726796AbgAWJRY (ORCPT + 99 others); Thu, 23 Jan 2020 04:17:24 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:36140 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725785AbgAWJRX (ORCPT ); Thu, 23 Jan 2020 04:17:23 -0500 Received: from [154.119.55.242] (helo=canonical.com) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iuYc5-00076Q-0F; Thu, 23 Jan 2020 09:17:21 +0000 From: Stefan Bader To: linux-kernel@vger.kernel.org, dm-devel@redhat.com, linux-block@vger.kernel.org Cc: Alasdair Kergon , Mike Snitzer , Jens Axboe , Tyler Hicks Subject: [PATCH 1/1] blk/core: Gracefully handle unset make_request_fn Date: Thu, 23 Jan 2020 11:17:13 +0200 Message-Id: <20200123091713.12623-2-stefan.bader@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200123091713.12623-1-stefan.bader@canonical.com> References: <20200123091713.12623-1-stefan.bader@canonical.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When device-mapper adapted for multi-queue functionality, they also re-organized the way the make-request function was set. Before, this happened when the device-mapper logical device was created. Now it is done once the mapping table gets loaded the first time (this also decides whether the block device is request or bio based). However in generic_make_request(), the request function gets used without further checks and this happens if one tries to mount such a partially set up device. This can easily be reproduced with the following steps: - dmsetup create -n test - mount /dev/dm-<#> /mnt This maybe is something which also should be fixed up in device- mapper. But given there is already a check for an unset queue pointer and potentially there could be other drivers which do or might do the same, it sounds like a good move to add another check to generic_make_request_checks() and to bail out if the request function has not been set, yet. BugLink: https://bugs.launchpad.net/bugs/1860231 Fixes: ff36ab34583a ("dm: remove request-based logic from make_request_fn wrapper") Signed-off-by: Stefan Bader --- block/blk-core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/block/blk-core.c b/block/blk-core.c index 1075aaff606d..adcd042edd2d 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -884,6 +884,13 @@ generic_make_request_checks(struct bio *bio) bio_devname(bio, b), (long long)bio->bi_iter.bi_sector); goto end_io; } + if (unlikely(!q->make_request_fn)) { + printk(KERN_ERR + "generic_make_request: Trying to access " + "block-device without request function: %s\n", + bio_devname(bio, b)); + goto end_io; + } /* * Non-mq queues do not honor REQ_NOWAIT, so complete a bio -- 2.17.1