Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp2039236pxb; Sun, 17 Apr 2022 07:45:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCsUF6sybTzX1usCW0/V1pOz2e8gX2I53aiQ1MwhNPqHqfycpOX3YN9RTUWWEmmj/4lPdF X-Received: by 2002:a63:5909:0:b0:399:b94:96f9 with SMTP id n9-20020a635909000000b003990b9496f9mr6700323pgb.622.1650206699818; Sun, 17 Apr 2022 07:44:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650206699; cv=none; d=google.com; s=arc-20160816; b=K1Rm4lXu764V77JkfXGBt4k2QK4tAFgj/i4vcuk0bSMXifmsRgEY1/rrI8OguTyVDl 9Dw89mHvBYGnY9nXVXMbEe8dkoTY8OFpogMkEAm8JXcVYlVNJzjxr7zxcd9dS0nYxgKs xwYsfjqr4Dp3DzlTb9FtoQVBqMDFPTCiB3nDnpHNqrRlBovn5xD/H2DkUD8ybK3mUX9t /ocP+fmn02u/T4/9OhXkWIrdHovN/Ys1lZBvELK09aL5OQkC+bZx2tGKdri9COS84Zdh CRYXojkERJQ8qDVQGEzAR6FCBKLeFd+RY7dYxJvISqFRXlSqX29+MetH99QzQpqhtUoj KT9Q== 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=/GqhBQnv4nLd0XXJ/xwIbyhSPhgvjfIm2xa+Q3qj4+w=; b=sPAtUcd/CDwoZ3cZCOgBO5BfwkuowwZnKXSCNGfteKOf1LiNb2vTrmU+bKKwzvHds+ LUrZxBXtg+iX1qBdkUelYjyInRxTST4d75BkR1ev3PJFvHfq51B26xQwWkQbPzzlrS7U fo8BkIJu89dPmQ4gG3Sf4Ms9Uy1ovbDxh97NQyQ7iro8aPsoD81ahuf3TBcc258EI1Ye OFHoN+Xy8+PT+GyRfh90osemzxOjrMo1oe00YKiKUvE/CXaeJmuq5Glo6MHB4Uqszzsz LmCRDltcXvAvxq5olzyPXGx51F3iklZjkO8qDKkxYPB+u7qUA1yf5v0l5XVfr4Nx6QSW BRFw== 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 d18-20020a056a0010d200b0050591ad7841si7225641pfu.237.2022.04.17.07.44.31; Sun, 17 Apr 2022 07:44:59 -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 S233592AbiDQIOP (ORCPT + 99 others); Sun, 17 Apr 2022 04:14:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34536 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230085AbiDQIOL (ORCPT ); Sun, 17 Apr 2022 04:14:11 -0400 Received: from fornost.hmeau.com (helcar.hmeau.com [216.24.177.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E459B387BD for ; Sun, 17 Apr 2022 01:11:36 -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 1ng009-003jBm-RT; Sun, 17 Apr 2022 18:11:23 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Sun, 17 Apr 2022 16:11:22 +0800 Date: Sun, 17 Apr 2022 16:11:22 +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 Fri, Apr 15, 2022 at 01:31:32PM +0100, Catalin Marinas wrote: > > This needs a clarification. For the above structure, kmalloc() will > return a 128-byte aligned pointer since sizeof(x) is a multiple of 128. > The potential problem is if you have something like: > > kmalloc(sizeof(struct x) + 64); > > The above could end up as a kmalloc(192) which is available with an > ARCH_KMALLOC_MINALIGN of 64. If that's a real use-case, I can change the > slab patch to not create the 192 (or 48 if we go for an even smaller > ARCH_KMALLOC_MINALIGN) caches and we'd always have ARCH_DMA_MINALIGN > guarantee if the structure itself is correctly aligned. No lying to the > compiler. Yes I suppose that should work: 1) Enlarge each crypto API object so that they're >= 128 bytes; 2) Modify kmalloc so that for sizes >= 128 bytes they're padded to multiples of 128. But it really feels like a hack. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt