From patchwork Thu Jan 23 08:33:02 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Bader X-Patchwork-Id: 1227721 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 483FsS35qWz9sR1; Thu, 23 Jan 2020 19:33:15 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1iuXvH-0001tm-LI; Thu, 23 Jan 2020 08:33:07 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iuXvG-0001tc-LO for kernel-team@lists.ubuntu.com; Thu, 23 Jan 2020 08:33:06 +0000 Received: from [154.119.55.246] (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 1iuXvG-0004AW-0K; Thu, 23 Jan 2020 08:33:06 +0000 From: Stefan Bader To: kernel-team@lists.ubuntu.com Subject: [SRU F/Unstable 0/1] Handle I/O on a blk device without request function Date: Thu, 23 Jan 2020 10:33:02 +0200 Message-Id: <20200123083303.11611-1-stefan.bader@canonical.com> X-Mailer: git-send-email 2.17.1 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tyler Hicks MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" This is to handle a situation which only recently started to be exercised but the underlying breakage has been around since 4.1 (Xenial onwards). The plan is to try getting this upstream and backported via stable as it is nothing that will happen accidental in a normal workflow. Just for the background, this was observed when uc20 started to support encrypted devices. During the initial setup, when the encrypted device is created, there is a short period of time (cryptsetup luksOpen does under the hood have first the device- mapper target without a mapping table and then supply the mapping) where the logical block device is around but has no function set up to do the I/O mapping. This stage already fires a uvent about the block device being added and this is acted on by a udev rule which only takes action when inside a snap, and this action attempts a mount which sends I/O to detect which (or wheteher) filesystem is on the block device/partition. And that causes a kernel crash. -Stefan Stefan Bader (1): UBUNTU: SAUCE: blk/core: Gracefully handle unset make_request_fn block/blk-core.c | 7 +++++++ 1 file changed, 7 insertions(+)