Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2972272imu; Sun, 9 Dec 2018 14:01:21 -0800 (PST) X-Google-Smtp-Source: AFSGD/W6LYfE/+5VqYXzlGCjODMZd84a990eEoEZEmNkjNuV2QzXfaeI4QY+qv+l9x1Bhs5XpqdW X-Received: by 2002:aa7:824f:: with SMTP id e15mr9213214pfn.192.1544392881619; Sun, 09 Dec 2018 14:01:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544392881; cv=none; d=google.com; s=arc-20160816; b=tKGNPD2s1QSSM0IRtO12QgoEzZce48qjZiBQSHN7WhtfZo3yeJjJQ0gUIcxXjJVz+x kOc4Ut4vReGJJFJsXlkWHSqokIubATvU5ZhkDbwcs62Bizs0Tnag1PG7vqZX1QaEhymO lSPpAbTotHqk8wZIRxMpxSFg87H+Dw5Lp/h/ir9xd+TgcKAiAf1vMojciJzI92TFDZUV BTfGwA3M+e+5LBFlpJLihIttq/NoHPPqUj/XFVHXOsPp9KM/OX2D/kG9Hte7iw+jiFQ4 /5u/yAn84oV6EWMPqlMYtAe6L66GlWGWzsejKDpedng79w3bq6rpLYGRIsIy88bcjE8j anBw== 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=TJb1s1UB662yaDb+fzyvgzMTlCvifXdKwhEtfgMYE9c=; b=inzcb60HcWD1o01n+1OP46kuuCq+YUkZ4HwI5sswBzF7Dy5BO+ARunjaDcMQa/5bop hZKSc1OgjTVgUHq7zIsV+8v/VReV4CnS7Y6KjmHn8KXfG+oXhsFnHGIyW52MoBg45chE s4KGDtmDESD5YZSIVzPVnUz5u5t2zrmm1YHwud/9bht5Hi4ZDe0Z3lXfwy6zx1jScTs6 5m2hR9E8wLuf6YT4EmDul5imOhIx+eS8wIHAvsWjdPxTi5D7UlbTfzO6ZjMqKqiGgvul HBQTduAaPL9Vo/YL6/gz9mhz71MjV1xvdS9eXAFuHHr/QYbDD89HAsSRdduK60gXrBSa FGAg== 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 z63si6982267pfz.132.2018.12.09.14.01.06; Sun, 09 Dec 2018 14:01:21 -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 S1726934AbeLIV7X (ORCPT + 99 others); Sun, 9 Dec 2018 16:59:23 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:36178 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726740AbeLIVzi (ORCPT ); Sun, 9 Dec 2018 16:55:38 -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 1gW730-0002if-QN; Sun, 09 Dec 2018 21:55:35 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gW72h-0003XR-3p; Sun, 09 Dec 2018 21:55:15 +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, "Mike Snitzer" , "Mikulas Patocka" 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 221/328] dm: disable CRYPTO_TFM_REQ_MAY_SLEEP to fix a GFP_KERNEL recursion deadlock 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: Mikulas Patocka commit 432061b3da64e488be3403124a72a9250bbe96d4 upstream. There's a XFS on dm-crypt deadlock, recursing back to itself due to the crypto subsystems use of GFP_KERNEL, reported here: https://bugzilla.kernel.org/show_bug.cgi?id=200835 * dm-crypt calls crypt_convert in xts mode * init_crypt from xts.c calls kmalloc(GFP_KERNEL) * kmalloc(GFP_KERNEL) recurses into the XFS filesystem, the filesystem tries to submit some bios and wait for them, causing a deadlock Fix this by updating both the DM crypt and integrity targets to no longer use the CRYPTO_TFM_REQ_MAY_SLEEP flag, which will change the crypto allocations from GFP_KERNEL to GFP_ATOMIC, therefore they can't recurse into a filesystem. A GFP_ATOMIC allocation can fail, but init_crypt() in xts.c handles the allocation failure gracefully - it will fall back to preallocated buffer if the allocation fails. The crypto API maintainer says that the crypto API only needs to allocate memory when dealing with unaligned buffers and therefore turning CRYPTO_TFM_REQ_MAY_SLEEP off is safe (see this discussion: https://www.redhat.com/archives/dm-devel/2018-August/msg00195.html ) Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer [bwh: Backported to 3.16: - Drop change to crypt_alloc_req_aead() in dm-crypt - Drop changes to dm-integrity - Adjust context] Signed-off-by: Ben Hutchings --- --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -262,7 +262,7 @@ static int crypt_iv_essiv_init(struct cr sg_init_one(&sg, cc->key, cc->key_size); desc.tfm = essiv->hash_tfm; - desc.flags = CRYPTO_TFM_REQ_MAY_SLEEP; + desc.flags = 0; err = crypto_hash_digest(&desc, &sg, cc->key_size, essiv->salt); if (err) @@ -533,7 +533,7 @@ static int crypt_iv_lmk_one(struct crypt int i, r; sdesc.desc.tfm = lmk->hash_tfm; - sdesc.desc.flags = CRYPTO_TFM_REQ_MAY_SLEEP; + sdesc.desc.flags = 0; r = crypto_shash_init(&sdesc.desc); if (r) @@ -690,7 +690,7 @@ static int crypt_iv_tcw_whitening(struct /* calculate crc32 for every 32bit part and xor it */ sdesc.desc.tfm = tcw->crc32_tfm; - sdesc.desc.flags = CRYPTO_TFM_REQ_MAY_SLEEP; + sdesc.desc.flags = 0; for (i = 0; i < 4; i++) { r = crypto_shash_init(&sdesc.desc); if (r) @@ -891,7 +891,7 @@ static void crypt_alloc_req(struct crypt ablkcipher_request_set_tfm(ctx->req, cc->tfms[key_index]); ablkcipher_request_set_callback(ctx->req, - CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP, + CRYPTO_TFM_REQ_MAY_BACKLOG, kcryptd_async_done, dmreq_of_req(cc, ctx->req)); }