Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp2658163pxb; Mon, 18 Apr 2022 05:45:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwf/MgeoVmjqMBLBDkLveQIoGmo/VzxCoAvuBrSiXJuCWL9Y4WjODCpVr28y3/GgcUgsma0 X-Received: by 2002:a05:6402:28b6:b0:41d:8c2e:c97e with SMTP id eg54-20020a05640228b600b0041d8c2ec97emr12182611edb.45.1650285908423; Mon, 18 Apr 2022 05:45:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650285908; cv=none; d=google.com; s=arc-20160816; b=oYJiG8uN1xr0AcoFWyKlvuLjPGhogj3Mshd3ldJXr33qUXQx/o9XDW61wiAFPyyFsu QbmqWyQWMyr+17Q9Z0YRjuDj1ttZemo0KI/z3jAPue6mFqg0yt3T9/VgSsjm4pIRrBkQ X9AKKEwl0D1mM6ZHxbneW7V7ryPqFP6frmR2md02cYeNHKvDKuWF1isu72XfobcUCRyP u1DYfaex0InLJ0rboU9riz4rNpOt15cHmitl5fTCGITa2+1fXtL9AvQ4S57KqqN7IwWN TeUvjmSvhcqA/qqU1Xo6NMTCdxBTwVUEnQs6Jh8yVVr9Fx3py47oGGYRWLX67w1T+O/m eF7g== 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=v8Nxh8+khIvz5lIt088rfa6TSPJajPorJ6Xf9E+uz+w=; b=emHl4RuaSc2YkpjDxSe1TIdiJBTpS0krtkcRUHmdFW5cKtP5VhpfbQYdWDE5j55Ouz rrlfQXGt5GPqDwiWlqH7wpiw6/NF8hF1rMKTESigX/UgybXdhVoMbxY86z4pQJJSWJCs TxKMymNP2+6zomyWBBDel9xjkSZrrjAjo31rkcqnjg0vxGZ8RiiAZ1uWcHpeYZufy+NA HEFM4yslrZsq8EBL9QFOvr1L3DnwpNJoFNrCLbigAt+yXa4kqIwUFJawogC3IX8Q1gH7 KpqOKYT8TNewshkf1iKXJodlpfJUMF1y4G+/m6sRPTnNCfY0KyNywYyp6Stf7jNlxBgt 0m4w== 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 l20-20020a170906079400b006e0f2761f3bsi5906010ejc.840.2022.04.18.05.44.44; Mon, 18 Apr 2022 05:45:08 -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 S233720AbiDQIq2 (ORCPT + 99 others); Sun, 17 Apr 2022 04:46:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233706AbiDQIqY (ORCPT ); Sun, 17 Apr 2022 04:46:24 -0400 Received: from fornost.hmeau.com (helcar.hmeau.com [216.24.177.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D640722BDA for ; Sun, 17 Apr 2022 01:43:48 -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 1ng0VJ-003jWG-6P; Sun, 17 Apr 2022 18:43:34 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Sun, 17 Apr 2022 16:43:33 +0800 Date: Sun, 17 Apr 2022 16:43:33 +0800 From: Herbert Xu To: Catalin Marinas Cc: Ard Biesheuvel , Will Deacon , Marc Zyngier , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , Linux Memory Management List , Linux ARM , Linux Kernel Mailing List , "David S. Miller" Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Message-ID: References: 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 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 Sun, Apr 17, 2022 at 09:38:40AM +0100, Catalin Marinas wrote: > > I don't think we need to do anything here. A structure like: > > struct x { > char y; > char z[] CRYPTO_MINALIGN_ATTR; > }; > > is already of size 128. Without CRYPTO_MINALIGN_ATTR, its size would be > 1 but otherwise the whole structure inherits the alignment of its > member and this translates into an aligned size. No we should not lie to the compiler, we have code elsewhere that uses the alignment to compute the amount of extra padding needed to create greater padding. If CRYPTO_MINALIGN is misleading then that calculation will fall apart. So keep CRYPTO_MINALIGN at whatever alignment you lower kmalloc to, and then add the padding you need to separate the Crypto API bits from the context. In fact, that is exactly what cra_alignmask is supposed to do. Sure we currently limit the maximum alignment to 64 bytes because of stack usage but we can certainly look into increasing it as that's what you're doing here anyway. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt