Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2844996imm; Fri, 24 Aug 2018 06:24:39 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYfHBdvMVPBG3Y3RXSUCb8NDSwha8TBJ/rtGdRXSIhzJhvQFDr56iscUoQFkA79GYN5YZWo X-Received: by 2002:a17:902:6b4c:: with SMTP id g12-v6mr1737070plt.159.1535117079458; Fri, 24 Aug 2018 06:24:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535117079; cv=none; d=google.com; s=arc-20160816; b=fRR4Ipl4Krv5aEtCi2T0DdH7U7YZ2iOro7+MlOwNQPT7zdGmkNF+7IA9C9/fhZeRbv YHnKXsPrKlgUUJ7BN6+ajm3sbtt8QD4L9IraDCclxm68DFSyX4fa/BpM2ODVUdmLwBHM RLcE0I7aIGYHZYP9scY2zsV7PTh8goNLCBAAILBfwURjibvZ9BlRSDCKcL+TMo/5ljf/ bEVlDblBtiKUcPSm2MBx7UXvapWvlZSZyJXvmQw1qZ4NhNOIa+O7p0X/wsotcoZPcDwi 38wO5ddeElc61GzX18dXBf6oCD9CsPo6TZkPAYIcbduk9TtyReoO/TC7czbL9pECSx3X 6cgQ== 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=El/RNsR8jdNhip0K4pK5f2k8+w6PiNEvySI7rMF8ZcE=; b=w6pYvyu1GVzB/quJYxxcYHI/FCaQ/bBGPsVL3On56uR3ZvfYySuJy/7JsA8LTI64BX z5RAKfeLrvjI9Dkm6OUrDFHa2wU+kmORg0Zpi9YwTBiTNRDX1ZIpYUtORAs8Y1BELbfL ndR7E/uUx2wrV7MQp41b6UlaCy83a3EVTM3LFwxWRr4nOAqjBVDbusgT9At5qVfbMwGF XlpOD+bVz/moNGrhsrIAALUo0aFfd9TAeTy4JY0SBdK11lQ0zQ7FFcrKbCGwPmvJusIn W7QdTklZfuL8ibB3up/yof+fWijHmLXrNy0QfYrJy8pd9kSDMxrpTV8JylEpRDqlm3fp d3eA== 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 o5-v6si6359403plh.18.2018.08.24.06.24.24; Fri, 24 Aug 2018 06:24:39 -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 S1727361AbeHXQ4b (ORCPT + 99 others); Fri, 24 Aug 2018 12:56:31 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:46222 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726883AbeHXQ4b (ORCPT ); Fri, 24 Aug 2018 12:56:31 -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 1ftC28-00088C-NQ; Fri, 24 Aug 2018 21:21:48 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1ftC25-0001WP-N2; Fri, 24 Aug 2018 21:21:45 +0800 Date: Fri, 24 Aug 2018 21:21:45 +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 Subject: Re: Deadlock when using crypto API for block devices Message-ID: <20180824132145.2zsnqwbih3iygeeq@gondor.apana.org.au> References: <20180824021010.hfar7gasp34ddrib@gondor.apana.org.au> <20180824112435.ggizlqrymuibm6oo@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: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? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt