From patchwork Mon Jun 1 16:03:36 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mikulas Patocka X-Patchwork-Id: 11582379 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 601BF157C for ; Mon, 1 Jun 2020 16:12:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 538D72073B for ; Mon, 1 Jun 2020 16:12:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726555AbgFAQMu (ORCPT ); Mon, 1 Jun 2020 12:12:50 -0400 Received: from smtp02.tmcz.cz ([93.153.104.113]:36072 "EHLO smtp02.tmcz.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726287AbgFAQMt (ORCPT ); Mon, 1 Jun 2020 12:12:49 -0400 Received: from smtp02.tmcz.cz (localhost [127.0.0.1]) by sagator.hkvnode045 (Postfix) with ESMTP id 1872694D525; Mon, 1 Jun 2020 18:04:24 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hkvnode046.tmo.cz X-Spam-Level: X-Spam-Status: No, score=0.4 required=8.0 tests=KHOP_HELO_FCRDNS autolearn=disabled version=3.3.1 X-Sagator-Scanner: 1.3.1-1 at hkvnode046; log(status(custom_action(quarantine(clamd()))), status(custom_action(quarantine(SpamAssassinD())))) X-Sagator-ID: 20200601-180424-0001-83035-TqdWZJ@hkvnode046 Received: from leontynka.twibright.com (109-183-129-149.customers.tmcz.cz [109.183.129.149]) by smtp02.tmcz.cz (Postfix) with ESMTPS; Mon, 1 Jun 2020 18:04:24 +0200 (CEST) Received: from debian-a64.vm ([192.168.208.2]) by leontynka.twibright.com with smtp (Exim 4.92) (envelope-from ) id 1jfmvG-0001W2-Ob; Mon, 01 Jun 2020 18:04:23 +0200 Received: by debian-a64.vm (sSMTP sendmail emulation); Mon, 01 Jun 2020 18:04:22 +0200 Message-Id: <20200601160421.912555280@debian-a64.vm> User-Agent: quilt/0.65 Date: Mon, 01 Jun 2020 18:03:36 +0200 From: Mikulas Patocka To: Mike Snitzer , Giovanni Cabiddu , Herbert Xu , "David S. Miller" , Milan Broz , djeffery@redhat.com Cc: dm-devel@redhat.com, qat-linux@intel.com, linux-crypto@vger.kernel.org, guazhang@redhat.com, jpittman@redhat.com, Mikulas Patocka Subject: [PATCH 4/4] dm-crypt: sleep and retry on allocation errors MIME-Version: 1.0 Content-Disposition: inline; filename=crypt-enomem.patch Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Some hardware crypto drivers use GFP_ATOMIC allocations in the request routine. These allocations can randomly fail - for example, they fail if too many network packets are received. If we propagated the failure up to the I/O stack, it would cause I/O errors and data corruption. So, we sleep and retry. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Index: linux-2.6/drivers/md/dm-crypt.c =================================================================== --- linux-2.6.orig/drivers/md/dm-crypt.c +++ linux-2.6/drivers/md/dm-crypt.c @@ -1534,6 +1534,7 @@ static blk_status_t crypt_convert(struct crypt_alloc_req(cc, ctx); atomic_inc(&ctx->cc_pending); +again: if (crypt_integrity_aead(cc)) r = crypt_convert_block_aead(cc, ctx, ctx->r.req_aead, tag_offset); else @@ -1541,6 +1542,17 @@ static blk_status_t crypt_convert(struct switch (r) { /* + * Some hardware crypto drivers use GFP_ATOMIC allocations in + * the request routine. These allocations can randomly fail. If + * we propagated the failure up to the I/O stack, it would cause + * I/O errors and data corruption. + * + * So, we sleep and retry. + */ + case -ENOMEM: + msleep(1); + goto again; + /* * The request was queued by a crypto driver * but the driver request queue is full, let's wait. */ From patchwork Tue Jun 2 11:53:05 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mikulas Patocka X-Patchwork-Id: 11583667 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id DE2E3739 for ; Tue, 2 Jun 2020 11:53:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C589D20772 for ; Tue, 2 Jun 2020 11:53:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HH8Yd7gT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726130AbgFBLxO (ORCPT ); Tue, 2 Jun 2020 07:53:14 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:34041 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726110AbgFBLxO (ORCPT ); Tue, 2 Jun 2020 07:53:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591098793; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Dt4SIhmc8J+qDrogNFXsD1xCPzLaE3ZqzBrlUatmphc=; b=HH8Yd7gTaQ8E9WIrizIAMwFbNJClt30sKsliWFJ1P6feVApfqtgBTHUbVUVtESE4ZaF4ym QfMZFwDhwHNado3etDn0kXxMRhLjwOvAdYg+rE6kTCmGvwQZN1HNOxVnqRkDXEWFPAMDJw aQmuByW0j2K8Su4pdBguraitATflS4I= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-318-4wbinrFPPy-6cY2Z0hlrUw-1; Tue, 02 Jun 2020 07:53:11 -0400 X-MC-Unique: 4wbinrFPPy-6cY2Z0hlrUw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C32B41052508; Tue, 2 Jun 2020 11:53:10 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BA67E5D9CC; Tue, 2 Jun 2020 11:53:07 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id 052Br7gp025558; Tue, 2 Jun 2020 07:53:07 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id 052Br5eN025554; Tue, 2 Jun 2020 07:53:05 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Tue, 2 Jun 2020 07:53:05 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Mike Snitzer , Giovanni Cabiddu , Herbert Xu , "David S. Miller" , Milan Broz , djeffery@redhat.com cc: dm-devel@redhat.com, qat-linux@intel.com, linux-crypto@vger.kernel.org, guazhang@redhat.com, jpittman@redhat.com Subject: [PATCH 5/4] dm-integrity: sleep and retry on allocation errors In-Reply-To: <20200601160421.912555280@debian-a64.vm> Message-ID: References: <20200601160421.912555280@debian-a64.vm> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org dm-integrity: sleep and retry on allocation errors Some hardware crypto drivers use GFP_ATOMIC allocations in the request routine. These allocations can randomly fail - for example, they fail if too many network packets are received. If we propagated the failure up to the I/O stack, it would cause I/O errors. So, we sleep and retry. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org --- drivers/md/dm-integrity.c | 5 +++++ 1 file changed, 5 insertions(+) Index: linux-2.6/drivers/md/dm-integrity.c =================================================================== --- linux-2.6.orig/drivers/md/dm-integrity.c 2020-04-05 21:11:02.000000000 +0200 +++ linux-2.6/drivers/md/dm-integrity.c 2020-06-02 13:49:36.000000000 +0200 @@ -859,6 +859,7 @@ static void complete_journal_encrypt(str static bool do_crypt(bool encrypt, struct skcipher_request *req, struct journal_completion *comp) { int r; +retry: skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG, complete_journal_encrypt, comp); if (likely(encrypt)) @@ -874,6 +875,10 @@ static bool do_crypt(bool encrypt, struc reinit_completion(&comp->ic->crypto_backoff); return true; } + if (r == -ENOMEM) { + msleep(1); + goto retry; + } dm_integrity_io_error(comp->ic, "encrypt", r); return false; }