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.9 04/21] devres: Align data[] to ARCH_KMALLOC_MINALIGN
Date: Wed, 22 Apr 2020 14:31:54 +0200 [thread overview]
Message-ID: <20200422123154.GA3144508@kroah.com> (raw)
In-Reply-To: <20200422111957.569589-5-lee.jones@linaro.org>
On Wed, Apr 22, 2020 at 12:19:40PM +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(-)
Sony ships this thing? Wow... Ok, I'll take it (for the next round),
but supposidly it only affected ARC systems, which I'm pretty sure are
not Sony phones :)
greg k-h
next prev parent reply other threads:[~2020-04-22 12:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 11:19 [PATCH 4.9 00/21] Backported fixes taken from Sony's Vendor tree Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 01/21] clk: qcom: rcg: Return failure for RCG update Lee Jones
2020-05-13 9:38 ` Greg KH
2020-04-22 11:19 ` [PATCH 4.9 02/21] drm/msm: stop abusing dma_map/unmap for cache Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 03/21] arm64: Fix size of __early_cpu_boot_status Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 04/21] devres: Align data[] to ARCH_KMALLOC_MINALIGN Lee Jones
2020-04-22 12:17 ` David Laight
2020-04-22 12:42 ` Geert Uytterhoeven
2020-04-22 12:31 ` Greg Kroah-Hartman [this message]
2020-04-23 11:58 ` Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 05/21] drm_dp_mst_topology: fix broken drm_dp_sideband_parse_remote_dpcd_read() Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 06/21] drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 07/21] clk: Fix debugfs_create_*() usage Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 08/21] Revert "gpio: set up initial state from .get_direction()" Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 09/21] arm64: traps: Don't print stack or raw PC/LR values in backtraces Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 10/21] scsi: ufs: Fix error handing during hibern8 enter Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 11/21] wil6210: increase firmware ready timeout Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 12/21] wil6210: fix temperature debugfs Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 13/21] scsi: ufs: make sure all interrupts are processed Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 14/21] scsi: ufs: ufs-qcom: remove broken hci version quirk Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 15/21] wil6210: rate limit wil_rx_refill error Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 16/21] rtc: pm8xxx: Fix issue in RTC write path Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 17/21] wil6210: fix length check in __wmi_send Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 18/21] soc: qcom: smem: Use le32_to_cpu for comparison Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 19/21] of: fix missing kobject init for !SYSFS && OF_DYNAMIC config Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 20/21] mm/vmalloc.c: move 'area->pages' after if statement Lee Jones
2020-04-22 11:19 ` [PATCH 4.9 21/21] usb: dwc3: don't set gadget->is_otg flag Lee Jones
2020-05-13 9:39 ` [PATCH 4.9 00/21] Backported fixes taken from Sony's Vendor tree Greg KH
2020-05-13 13:13 ` Lee Jones
2020-05-13 13:16 ` Greg KH
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=20200422123154.GA3144508@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 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.