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=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT 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 800EFC10F0E for ; Thu, 18 Apr 2019 04:08:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 562902184B for ; Thu, 18 Apr 2019 04:08:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725785AbfDREIA (ORCPT ); Thu, 18 Apr 2019 00:08:00 -0400 Received: from [128.1.224.119] ([128.1.224.119]:34742 "EHLO deadmen.hmeau.com" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725710AbfDREH7 (ORCPT ); Thu, 18 Apr 2019 00:07:59 -0400 X-Greylist: delayed 1884 seconds by postgrey-1.27 at vger.kernel.org; Thu, 18 Apr 2019 00:07:59 EDT 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 1hGxqd-0000T9-Ne; Thu, 18 Apr 2019 11:36:27 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1hGxqX-0007Wg-6Y; Thu, 18 Apr 2019 11:36:21 +0800 Date: Thu, 18 Apr 2019 11:36:21 +0800 From: Herbert Xu To: Ard Biesheuvel Cc: Pascal Van Leeuwen , Eric Biggers , "linux-crypto@vger.kernel.org" Subject: Re: Question regarding crypto scatterlists / testmgr Message-ID: <20190418033621.fnj72tffc3exfh3b@gondor.apana.org.au> References: <20190417202407.GA96242@gmail.com> 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-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Wed, Apr 17, 2019 at 08:29:59PM -0700, Ard Biesheuvel wrote: > > Seems like I was misreading the code: we have the following code in > skcipher_walk_next > > if (!err && (walk->flags & SKCIPHER_WALK_PHYS)) { > walk->src.phys.page = virt_to_page(walk->src.virt.addr); > walk->dst.phys.page = virt_to_page(walk->dst.virt.addr); > walk->src.phys.offset &= PAGE_SIZE - 1; > walk->dst.phys.offset &= PAGE_SIZE - 1; > } > > but all that does is normalize the offset. In fact, this code looks > slightly dodgy to me, given that, if the offset /does/ exceed > PAGE_SIZE, it normalizes the offset but does not advance the page > pointers accordingly. I wouldn't be surprised if the async walk code is buggy. Hardly anybody uses this. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt