Received: by 2002:a05:6a10:144:0:0:0:0 with SMTP id 4csp129857pxw; Fri, 8 Apr 2022 03:19:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy4JevEhtv8QdS7liQMwNH20Wk0UYm/qAa8K3J/D1XEQ4uKBUTrOScvwIhWnX5vtbR5E2Qs X-Received: by 2002:a17:907:2d8d:b0:6df:a06c:7c55 with SMTP id gt13-20020a1709072d8d00b006dfa06c7c55mr17710672ejc.325.1649413166971; Fri, 08 Apr 2022 03:19:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649413166; cv=none; d=google.com; s=arc-20160816; b=zmgmcPtoLsDu7fmH99x3H9GAB9mTt/3exTIjEn/rbZn/cbwzFx6ISHZf99zokyCdXE SIucp/jyfI37ofhRWBS3eDtESunqqoOMxnNiKidk9zHfy2nVBnHtbdyUZSbYjiBUeCRF 946L+6VJlwZJ2DDYAA9Hi4AkKOwXTKk9lJ660gLbWmiQ3Q6gwwWAFcsZW91ekygJDMHI dmsJBDrfKWKIMnsQWc/jXgdK0JGPke3Ca2mMdZQaroAImQ5/ir9AoJJ3FAjrCtzZC/uL OsFaTmc732Wy+n5Fzj4OinJ9nX47vWjo27UGNLw3DHUlhCsHcLRAXz5iNPtSUYcmaY+d YwDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=SkFQqHjhzpnJZNaNwjpLpeauLlyuyGe3rXoawhL2qTI=; b=c/+VAW9dOvg8xbT2L1zaC6VX732gLv+2+ugElwI0VKbAMg6vdy4BVbUfhEISY3IAXo UtLTQnq8KuIHKAKnOghzEXoV4/TgNvBuWeo2wofg5WV3Z1x20yFb7s2b9y0WIOZl8p4z dwEcRqIW3RAWQHvxQ7pxzbodmKvpsDlhRh/uEjAbOLBk9LdAGLQF9fh1y19JADY5mjeC Lxrop+5PtwGtdrxr+u3fx4Yuj7zCcC+4LS0ZAw+zUykIjxTlof+RbWtYOxgBqstoEneP D2I/r0PITufJGMjfSZLPWAorAqy/nDO2NkFBzNIDtF1GKPAaudFA04v1pTSTqZ+44dM9 TnKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d14-20020a50f68e000000b00418c2b5bd7asi532590edn.92.2022.04.08.03.19.01; Fri, 08 Apr 2022 03:19:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232157AbiDHJU0 (ORCPT + 99 others); Fri, 8 Apr 2022 05:20:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233209AbiDHJOj (ORCPT ); Fri, 8 Apr 2022 05:14:39 -0400 Received: from fornost.hmeau.com (helcar.hmeau.com [216.24.177.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9AE812B75B for ; Fri, 8 Apr 2022 02:11:47 -0700 (PDT) Received: from gwarestrin.arnor.me.apana.org.au ([192.168.103.7]) by fornost.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1nckeN-000Szc-Vn; Fri, 08 Apr 2022 19:11:29 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Fri, 08 Apr 2022 17:11:28 +0800 Date: Fri, 8 Apr 2022 17:11:28 +0800 From: Herbert Xu To: Catalin Marinas Cc: Ard Biesheuvel , Will Deacon , Marc Zyngier , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "David S. Miller" Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Message-ID: References: <20220405135758.774016-8-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 08, 2022 at 10:04:54AM +0100, Catalin Marinas wrote: > > My point is that if the crypto code kmallocs a size aligned to > crypto_tfm_ctx_alignment() (and CRYPTO_MINALIGN), the slab allocator > will return memory aligned to CRYPTO_MINALIGN even if > ARCH_KMALLOC_MINALIGN is smaller. No we don't align the size to CRYPTO_MINALIGN at all. We simply assume that this is the alignment returned by kmalloc. > Would the crypto code, say, do a kmalloc(64) and expect a 128 byte > alignment (when CRYPTO_MINALIGN == 128)? Or does it align the size to > CRYPTO_MINALIGN and do a kmalloc(128) directly? If it's the latter, I > don't think there's a problem. It's the former. I think you can still make the change you want, but first you need to modify the affected drivers to specify their actual alignment requirement explicitly through cra_alignmask and then use the correct methods to access the context pointer. Basically these drivers have been broken from day one, but their brokenness has been hidden by the extra-large KMALLOC_MINALIGN value on arm. So to reduce the KMALLOC_MINALIGN value, you have to modify the drivers and set the cra_alignmask value. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt