Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2844815imm; Fri, 24 Aug 2018 06:24:27 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaLT4McqKwwzJY6z/fYRtN0OVQV+5lnSjKLLJ9dHGm1JcAPgjL72lpbMCE1+TCfAFclck+X X-Received: by 2002:a63:db4f:: with SMTP id x15-v6mr1673155pgi.214.1535117067159; Fri, 24 Aug 2018 06:24:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535117067; cv=none; d=google.com; s=arc-20160816; b=l0UOYA2QAIjzHHW/AvGQPUh7vRkkdi5AiF7+W/hXovqDxqkGoeokCU+atSTq4NwH/P DGJH1BSuP+I8l8QjNccZ5jt/pOmLO482/TpE2IvDtcvYZitFoYRS7YKc/nLjc5VYLfK0 9N8QY/0F0cOixHZ5jfKr8lP4KsDW3ignFwRiJFzgIKuFT7axd3eMAm2uYSym2nv4QVlG UaeuamP2P7i3BhkeGSp2cpR2U68xiL3ipH4FiGDEYLngHnb3BHQniFBc04sM225Z5GaW +Nqbtq0KqocO866AiLPPvm6IIkypxXD0XGMC/Hvv1toBqlsEGTRCtNPHQYKm5isDqRAv 2rag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=rHCzmthJ3w/dhTNe68cc1cu/wGXfTYuYinRNRyNUVKU=; b=APH9vGaRu4G0O+638XTzIv9yd8SJO3LwzMeeToDaSHmGunkOSWF7Dbxh/1yz+5T7HO KoruopIHbKcg4ErX3ovjBmwUDCnsinT49kZktOsPXt8kzdbmJpgm9nhykZCZJhTF6V+N eHDFOTM61CEerAgRK/rGfAeeXkhldFMktNqRaBPEtRqGgx2pcBromu9GEMCkNPJOUrur aYONJ0KqANkMZ2ew6dJHGBwJMkg2MQunRMvrXBsotvFLRVia9hQ/gwvFOvS4qXXaDO4f 6PixMBuedroKWDI0Fhxo+NzHYHZgNmZWy13jnQAV56BxeS5qn5ajTyOkescq0qksJ6lK db4w== 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 33-v6si6948998ply.251.2018.08.24.06.24.11; Fri, 24 Aug 2018 06:24:27 -0700 (PDT) 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 S1727875AbeHXQ5Q (ORCPT + 99 others); Fri, 24 Aug 2018 12:57:16 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:46228 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727615AbeHXQ5Q (ORCPT ); Fri, 24 Aug 2018 12:57:16 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1ftC2q-0008CC-JY; Fri, 24 Aug 2018 21:22:32 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1ftC2p-0001X1-FB; Fri, 24 Aug 2018 21:22:31 +0800 Date: Fri, 24 Aug 2018 21:22:31 +0800 From: Herbert Xu To: Mikulas Patocka Cc: "David S. Miller" , linux-crypto@vger.kernel.org, Mike Snitzer , dm-devel@redhat.com, linux-kernel@vger.kernel.org, Dave Watson Subject: Re: Deadlock when using crypto API for block devices Message-ID: <20180824132231.t3narmsfcykseeee@gondor.apana.org.au> References: <20180824021010.hfar7gasp34ddrib@gondor.apana.org.au> <20180824112435.ggizlqrymuibm6oo@gondor.apana.org.au> <20180824132145.2zsnqwbih3iygeeq@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180824132145.2zsnqwbih3iygeeq@gondor.apana.org.au> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 24, 2018 at 09:21:45PM +0800, Herbert Xu wrote: > On Fri, Aug 24, 2018 at 09:00:00AM -0400, Mikulas Patocka wrote: > > > > BTW. gcmaes_crypt_by_sg also contains GFP_ATOMIC and -ENOMEM, behind a > > pretty complex condition. Do you mean that this condition is part of the > > contract that the crypto API provides? > > This is an implementation defect. I think for this case we should > fall back to software GCM if the accelerated version fails. > > > Should "req->src->offset + req->src->length < PAGE_SIZE" use "<=" instead? > > Because if the data ends up at page boundary, it will use the atomic > > allocation that can fail. > > This condition does look strange. It's introduced by the commit > e845520707f85c539ce04bb73c6070e9441480be. Dave, what exactly is > it meant to do? I forgot to Cc Dave Watson. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt