From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA050C433DB for ; Fri, 1 Jan 2021 10:58:50 +0000 (UTC) Received: from mail.server123.net (mail.server123.net [78.46.64.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 64896221EC for ; Fri, 1 Jan 2021 10:58:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64896221EC Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=cloudflare.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dm-crypt-bounces@saout.de X-Virus-Scanned: amavisd-new at saout.de Authentication-Results: mail.server123.net (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::131; helo=mail-il1-x131.google.com; envelope-from=ignat@cloudflare.com; receiver= Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Fri, 1 Jan 2021 11:26:59 +0100 (CET) Received: by mail-il1-x131.google.com with SMTP id 75so19086702ilv.13 for ; Fri, 01 Jan 2021 02:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k2vQ6iqC4CndNBeiIFLrfo2PMRh+mcqERP0ZLSMI0UU=; b=S2e0UyON57vBfV4TYhF3yPrS2nbggdWhKASDKkJyyZhZZrjDkAVKHQZ26oCiBGwSFX UDzTX28rWXZcodt0np0keMnUqzYQ17/DQTLTwwfR+nqTnbOIeJKrun6JulieBxrFKNb6 sijYwADkpBgOOo7LwIp5zStNDZK3l0kIytvlw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k2vQ6iqC4CndNBeiIFLrfo2PMRh+mcqERP0ZLSMI0UU=; b=G5oEB4I9BSzZKquu1YLRtsX/41y/Fhh1OvnszhxN2wxFjHHeT8KephZYEwAU/bAQWd tpBkh6QAFzF3qwyBjX075CfiKdMxAuLRhAAciMrvd3GQKaYnnvo8Jc5VRoKjN11DLLa6 KzUxXrnFOCqON/vvPz8fE3fIY3JiOWEorKGU4QBMUhgr1JHGiQIu/XblVLJjFZQwjTFW I8nkCOILxYS5hJRxXHwh386Eky9nQ4R3DEfY/038Wq/ecNUWHX70juxDY8xteYZf0mDq hxl9KD8H6TeGxRPjMv5oxpPA/CqGt18gh8O8vwQGrZTBhp0Z34VmM89NQnaurRpinMfn UNvQ== X-Gm-Message-State: AOAM532XOjf5BUjClmPdGytARR9xMV6x3X/KVB18+rriYSM3feo4Z5Vv ZfzyCh7Y3Zw44ftfTB80nOH+gdwHyL7/j8gaal29ZA== X-Google-Smtp-Source: ABdhPJz1USMv6E2KC8ZVmIWBjUJhlS5f9B0ew9hFe2xL6yHufIj3i5Q+DJrMQoaeY+K+o+6kwBrDtzQTcfz8CCZkwqA= X-Received: by 2002:a92:c990:: with SMTP id y16mr60036119iln.35.1609496817666; Fri, 01 Jan 2021 02:26:57 -0800 (PST) MIME-Version: 1.0 References: <20201230214520.154793-1-ignat@cloudflare.com> <20201230214520.154793-2-ignat@cloudflare.com> In-Reply-To: From: Ignat Korchagin Date: Fri, 1 Jan 2021 10:26:46 +0000 Message-ID: To: Mikulas Patocka X-Mailman-Approved-At: Fri, 01 Jan 2021 11:55:31 +0100 Subject: Re: [dm-crypt] [PATCH v2 1/2] dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq X-BeenThere: dm-crypt@saout.de X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Damien Le Moal , Herbert Xu , Mike Snitzer , kernel-team , dm-crypt@saout.de, linux-kernel , stable@vger.kernel.org, Nobuto Murata , Eric Biggers , Chris Mason , device-mapper development , linux-btrfs@vger.kernel.org, David Sterba , Josef Bacik , "Maciej S. Szmigiero" , Alasdair G Kergon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dm-crypt-bounces@saout.de Sender: "dm-crypt" On Fri, Jan 1, 2021 at 10:00 AM Mikulas Patocka wrote: > > > > On Wed, 30 Dec 2020, Ignat Korchagin wrote: > > > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > > index 53791138d78b..e4fd690c70e1 100644 > > --- a/drivers/md/dm-crypt.c > > +++ b/drivers/md/dm-crypt.c > > @@ -1539,7 +1549,10 @@ static blk_status_t crypt_convert(struct crypt_config *cc, > > > > while (ctx->iter_in.bi_size && ctx->iter_out.bi_size) { > > > > - crypt_alloc_req(cc, ctx); > > + r = crypt_alloc_req(cc, ctx); > > + if (r) > > + return BLK_STS_RESOURCE; > > + > > atomic_inc(&ctx->cc_pending); > > > > if (crypt_integrity_aead(cc)) > > -- > > 2.20.1 > > I'm not quite convinced that returning BLK_STS_RESOURCE will help. The > block layer will convert this value back to -ENOMEM and return it to the > caller, resulting in an I/O error. > > Note that GFP_ATOMIC allocations may fail anytime and you must handle > allocation failure gracefully - i.e. process the request without any > error. > > An acceptable solution would be to punt the request to a workqueue and do > GFP_NOIO allocation from the workqueue. Or add the request to some list > and process the list when some other request completes. We can do the workqueue, if that's the desired behaviour. The second patch from this patchset already adds the code for the request to be retried from the workqueue if crypt_convert returns BLK_STS_DEV_RESOURCE, so all is needed is to change returning BLK_STS_RESOURCE to BLK_STS_DEV_RESOURCE here. Does that sound reasonable? > You should write a test that simulates allocation failure and verify that > the kernel handles it gracefully without any I/O error. I already have the test for the second patch in the set, but will adapt it to make sure the allocation failure codepath is covered as well. > Mikulas > _______________________________________________ dm-crypt mailing list dm-crypt@saout.de https://www.saout.de/mailman/listinfo/dm-crypt