From mboxrd@z Thu Jan 1 00:00:00 1970 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=-6.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 0CDFDCA90AF for ; Wed, 13 May 2020 09:48:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC98420740 for ; Wed, 13 May 2020 09:48:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733147AbgEMJsz (ORCPT ); Wed, 13 May 2020 05:48:55 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:44584 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733142AbgEMJsy (ORCPT ); Wed, 13 May 2020 05:48:54 -0400 Received: by mail-oi1-f194.google.com with SMTP id a2so20691588oia.11 for ; Wed, 13 May 2020 02:48:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fr/hy8F1vxP95AbuYdAfrvnascV7pBsA9t1Mh9K1dKU=; b=icO7XEBavTeloiX+21ejGMh0cOKe+19OZB5Z5F/Zm85V5IX4BZor2I8vnwizJEr9ar G7P5SpmLJDnIolt61uUl1ksembBxqMXrJe96elwhedGZPuhAUfIzO58Zcx54SmtP/svE 3htWsBc8JQLbCEeL5k1jmLSUmv1skUZO6MGF73qE9e5ZqWwxh6zb8rIH5NMf3UM8q6Qe YEaETYbvBUicNCUsh2PBr0b+qvNQ9evkqNvneUsscuo1wBj/gQ/q+WG5SDSjgYkcEIOR y+TOIiWg+/XP4O8uD/mchkI/7AaqPYFEzQyJl1F3WYBcwH5EyDOdiXQ1BNZKF9VK74yj WUUA== X-Gm-Message-State: AGi0PuaJQoUD3wpEsQz1mLmEnp4C6h1QgL1IZpyAXiO0zgBP7h3Px05Q nZWGZCERs+8Emcetr8tLqUXsJK5Z3shmVOpNUpg= X-Google-Smtp-Source: APiQypJXNJUD6gHbOFzjjTyouS+H1NbLqxkhcP4LJ1f8IlIXwsGga4gZKHnraarnoddknIM2jBdwu+OHmwapaoEUx4k= X-Received: by 2002:aca:895:: with SMTP id 143mr25512062oii.153.1589363333369; Wed, 13 May 2020 02:48:53 -0700 (PDT) MIME-Version: 1.0 References: <20200423204014.784944-1-lee.jones@linaro.org> <20200423204014.784944-4-lee.jones@linaro.org> <20200513093536.GB830571@kroah.com> In-Reply-To: <20200513093536.GB830571@kroah.com> From: Geert Uytterhoeven Date: Wed, 13 May 2020 11:48:42 +0200 Message-ID: Subject: Re: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN To: Greg Kroah-Hartman Cc: Lee Jones , stable , Alexey Brodkin , Alexey Brodkin , David Laight , Peter Zijlstra , Thomas Gleixner , Vineet Gupta , Will Deacon Content-Type: text/plain; charset="UTF-8" Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org Hi Greg, On Wed, May 13, 2020 at 11:35 AM Greg Kroah-Hartman wrote: > On Thu, Apr 23, 2020 at 09:40:01PM +0100, Lee Jones wrote: > > From: Alexey Brodkin > > > > [ Upstream commit a66d972465d15b1d89281258805eb8b47d66bd36 ] > > > > Initially we bumped into problem with 32-bit aligned atomic64_t > > on ARC, see [1]. And then during quite lengthly discussion Peter Z. > > mentioned ARCH_KMALLOC_MINALIGN which IMHO makes perfect sense. > > If allocation is done by plain kmalloc() obtained buffer will be > > ARCH_KMALLOC_MINALIGN aligned and then why buffer obtained via > > devm_kmalloc() should have any other alignment? > > > > This way we at least get the same behavior for both types of > > allocation. > > > > [1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004009.html > > [2] http://lists.infradead.org/pipermail/linux-snps-arc/2018-July/004036.html > > > > Signed-off-by: Alexey Brodkin > > Cc: Greg Kroah-Hartman > > Cc: Geert Uytterhoeven > > Cc: David Laight > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: Vineet Gupta > > Cc: Will Deacon > > Cc: Greg KH > > Cc: # 4.8+ > > Signed-off-by: Greg Kroah-Hartman > > Signed-off-by: Lee Jones > > --- > > drivers/base/devres.c | 10 ++++++++-- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/base/devres.c b/drivers/base/devres.c > > index 8fc654f0807bf..9763325a9c944 100644 > > --- a/drivers/base/devres.c > > +++ b/drivers/base/devres.c > > @@ -24,8 +24,14 @@ struct devres_node { > > > > struct devres { > > struct devres_node node; > > - /* -- 3 pointers */ > > - unsigned long long data[]; /* guarantee ull alignment */ > > + /* > > + * Some archs want to perform DMA into kmalloc caches > > + * and need a guaranteed alignment larger than > > + * the alignment of a 64-bit integer. > > + * Thus we use ARCH_KMALLOC_MINALIGN here and get exactly the same > > + * buffer alignment as if it was allocated by plain kmalloc(). > > + */ > > + u8 __aligned(ARCH_KMALLOC_MINALIGN) data[]; > > }; > > > > struct devres_group { > > -- > > 2.25.1 > > > > I don't want to apply this to older kernels as it could cause extra > memory usage for no good reason. I have no idea why a non ARC system > would want it :( I think the reference to ARC is a red herring. The real issue is that buffers used for DMA may not have the required alignment, which is not limited to ARC systems. Note that I'm also not super happy with the extra memory usage. But devm_*() conveniences come with their penalties... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds