From: Mikulas Patocka Subject: Re: Deadlock when using crypto API for block devices Date: Fri, 24 Aug 2018 09:00:00 -0400 (EDT) Message-ID: References: <20180824021010.hfar7gasp34ddrib@gondor.apana.org.au> <20180824112435.ggizlqrymuibm6oo@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "David S. Miller" , linux-crypto@vger.kernel.org, Mike Snitzer , dm-devel@redhat.com, linux-kernel@vger.kernel.org To: Herbert Xu Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On Fri, 24 Aug 2018, Mikulas Patocka wrote: > > > On Fri, 24 Aug 2018, Herbert Xu wrote: > > > On Fri, Aug 24, 2018 at 07:06:32AM -0400, Mikulas Patocka wrote: > > > > > > A quick search through the crypto code shows that ahash_save_req and > > > seqiv_aead_encrypt return -ENOMEM. > > > > > > Will you fix them? > > > > These only trigger for unaligned buffers. It would be much better > > if dm-crypt can ensure that the input/output is properly unaligned > > and if otherwise do the allocation in dm-crypt. > > But we are relying here on an implementation detail and not on contract. > > Mikulas 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? 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. Mikulas