stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: stable@vger.kernel.org,
	Alexey Brodkin <alexey.brodkin@synopsys.com>,
	Alexey Brodkin <abrodkin@synopsys.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	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:35:36 +0200	[thread overview]
Message-ID: <20200513093536.GB830571@kroah.com> (raw)
In-Reply-To: <20200423204014.784944-4-lee.jones@linaro.org>

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 :(

greg k-h

  reply	other threads:[~2020-05-13  9:35 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 [this message]
2020-05-13  9:48     ` Geert Uytterhoeven
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=20200513093536.GB830571@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=David.Laight@aculab.com \
    --cc=abrodkin@synopsys.com \
    --cc=alexey.brodkin@synopsys.com \
    --cc=geert@linux-m68k.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).