All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lee Jones <lee.jones@linaro.org>, stable <stable@vger.kernel.org>,
	Alexey Brodkin <alexey.brodkin@synopsys.com>,
	Alexey Brodkin <abrodkin@synopsys.com>,
	David Laight <David.Laight@aculab.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vineet Gupta <vgupta@synopsys.com>,
	Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN
Date: Wed, 13 May 2020 11:48:42 +0200	[thread overview]
Message-ID: <CAMuHMdVZHodDXGOMuOpVLbgiy9_WeHHKKq4kG7Cz9u9pm8UZuw@mail.gmail.com> (raw)
In-Reply-To: <20200513093536.GB830571@kroah.com>

Hi Greg,

On Wed, May 13, 2020 at 11:35 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 23, 2020 at 09:40:01PM +0100, Lee Jones wrote:
> > From: Alexey Brodkin <alexey.brodkin@synopsys.com>
> >
> > [ 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 <abrodkin@synopsys.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: David Laight <David.Laight@ACULAB.COM>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Vineet Gupta <vgupta@synopsys.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Greg KH <greg@kroah.com>
> > Cc: <stable@vger.kernel.org> # 4.8+
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  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

  reply	other threads:[~2020-05-13  9:48 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-23 20:39 [PATCH 4.4 00/16] Backported fixes taken from Sony's Vendor tree Lee Jones
2020-04-23 20:39 ` [PATCH 4.4 01/16] drm/msm: stop abusing dma_map/unmap for cache Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 02/16] gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants Lee Jones
2020-05-13  9:34   ` Greg KH
2020-05-18 10:23   ` [PATCH 4.4 02/16 (v2)] " Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 03/16] devres: Align data[] to ARCH_KMALLOC_MINALIGN Lee Jones
2020-05-13  9:35   ` Greg Kroah-Hartman
2020-05-13  9:48     ` Geert Uytterhoeven [this message]
2020-05-13 10:10       ` David Laight
2020-05-13 11:05         ` Geert Uytterhoeven
2020-05-13 11:06           ` Geert Uytterhoeven
2020-05-13 12:37             ` David Laight
2020-05-13 13:26               ` Geert Uytterhoeven
2020-05-13 13:35                 ` David Laight
2020-05-13 13:36         ` Peter Zijlstra
2020-05-13 13:50           ` David Laight
2020-04-23 20:40 ` [PATCH 4.4 04/16] crypto: talitos - Delete an error message for a failed memory allocation in talitos_edesc_alloc() Lee Jones
2020-05-13  9:36   ` Greg KH
2020-05-18 10:17     ` Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 05/16] drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem Lee Jones
2020-05-13  9:36   ` Greg KH
2020-04-23 20:40 ` [PATCH 4.4 06/16] clk: Fix debugfs_create_*() usage Lee Jones
2020-05-13  9:37   ` Greg KH
2020-05-18 10:08     ` Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 07/16] arm64: traps: Don't print stack or raw PC/LR values in backtraces Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 08/16] serial/sunsu: add missing of_node_put() Lee Jones
2020-05-06  8:23   ` Greg Kroah-Hartman
2020-05-06  9:02     ` Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 09/16] wil6210: increase firmware ready timeout Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 10/16] wil6210: fix temperature debugfs Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 11/16] scsi: ufs: ufs-qcom: remove broken hci version quirk Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 12/16] wil6210: rate limit wil_rx_refill error Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 13/16] rtc: pm8xxx: Fix issue in RTC write path Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 14/16] soc: qcom: smem: Use le32_to_cpu for comparison Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 15/16] of: fix missing kobject init for !SYSFS && OF_DYNAMIC config Lee Jones
2020-04-23 20:40 ` [PATCH 4.4 16/16] mm/vmalloc.c: move 'area->pages' after if statement Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMuHMdVZHodDXGOMuOpVLbgiy9_WeHHKKq4kG7Cz9u9pm8UZuw@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=David.Laight@aculab.com \
    --cc=abrodkin@synopsys.com \
    --cc=alexey.brodkin@synopsys.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee.jones@linaro.org \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vgupta@synopsys.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.