A recent review of the Sony Xperia Development kernel tree [0] resulted in the discovery of various patches which have been backported from Mainline in order to fix an array of issues. These patches should be applied to Stable such that everyone can benefit from them.
Note: The review is still on-going (~50%) - more to follow.
[0] https://github.com/sonyxperiadev/kernel
Alexey Brodkin (1): devres: Align data[] to ARCH_KMALLOC_MINALIGN
Austin Kim (1): mm/vmalloc.c: move 'area->pages' after if statement
Chris Lew (1): soc: qcom: smem: Use le32_to_cpu for comparison
Dedy Lansky (2): wil6210: fix temperature debugfs wil6210: rate limit wil_rx_refill error
Geert Uytterhoeven (2): gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants clk: Fix debugfs_create_*() usage
Hamad Kadmany (1): wil6210: increase firmware ready timeout
Joe Moriarty (1): drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
Markus Elfring (1): crypto: talitos - Delete an error message for a failed memory allocation in talitos_edesc_alloc()
Mohit Aggarwal (1): rtc: pm8xxx: Fix issue in RTC write path
Rob Clark (1): drm/msm: stop abusing dma_map/unmap for cache
Rob Herring (1): of: fix missing kobject init for !SYSFS && OF_DYNAMIC config
Subhash Jadavani (1): scsi: ufs: ufs-qcom: remove broken hci version quirk
Will Deacon (1): arm64: traps: Don't print stack or raw PC/LR values in backtraces
Yangtao Li (1): serial/sunsu: add missing of_node_put()
arch/arm64/kernel/process.c | 9 ++- arch/arm64/kernel/traps.c | 72 +--------------------- drivers/base/devres.c | 10 ++- drivers/clk/clk.c | 30 +++++---- drivers/crypto/talitos.c | 1 - drivers/gpio/gpiolib.c | 8 +-- drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++- drivers/gpu/drm/msm/msm_gem.c | 4 +- drivers/net/wireless/ath/wil6210/debugfs.c | 7 ++- drivers/net/wireless/ath/wil6210/main.c | 2 +- drivers/net/wireless/ath/wil6210/txrx.c | 4 +- drivers/of/base.c | 3 - drivers/rtc/rtc-pm8xxx.c | 49 +++++++++++---- drivers/scsi/ufs/ufs-qcom.c | 2 +- drivers/soc/qcom/smem.c | 2 +- drivers/tty/serial/sunsu.c | 20 ++++-- mm/vmalloc.c | 8 ++- 17 files changed, 107 insertions(+), 132 deletions(-)
From: Rob Clark robdclark@chromium.org
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451 __iommu_dma_unmap+0xb8/0xc0 Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo cfg80211 videobuf2_vmalloc videobuf2_memops vide CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: G W 5.2.0-rc5-next-20190619+ #2317 Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018 Workqueue: msm msm_gem_free_work [msm] pstate: 80c00005 (Nzcv daif +PAN +UAO) pc : __iommu_dma_unmap+0xb8/0xc0 lr : __iommu_dma_unmap+0x54/0xc0 sp : ffff0000119abce0 x29: ffff0000119abce0 x28: 0000000000000000 x27: ffff8001f9946648 x26: ffff8001ec271068 x25: 0000000000000000 x24: ffff8001ea3580a8 x23: ffff8001f95ba010 x22: ffff80018e83ba88 x21: ffff8001e548f000 x20: fffffffffffff000 x19: 0000000000001000 x18: 00000000c00001fe x17: 0000000000000000 x16: 0000000000000000 x15: ffff000015b70068 x14: 0000000000000005 x13: 0003142cc1be1768 x12: 0000000000000001 x11: ffff8001f6de9100 x10: 0000000000000009 x9 : ffff000015b78000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : fffffffffffff000 x5 : 0000000000000fff x4 : ffff00001065dbc8 x3 : 000000000000000d x2 : 0000000000001000 x1 : fffffffffffff000 x0 : 0000000000000000 Call trace: __iommu_dma_unmap+0xb8/0xc0 iommu_dma_unmap_sg+0x98/0xb8 put_pages+0x5c/0xf0 [msm] msm_gem_free_work+0x10c/0x150 [msm] process_one_work+0x1e0/0x330 worker_thread+0x40/0x438 kthread+0x12c/0x130 ret_from_fork+0x10/0x18 ---[ end trace afc0dc5ab81a06bf ]---
Not quite sure what triggered that, but we really shouldn't be abusing dma_{map,unmap}_sg() for cache maint.
Cc: Stephen Boyd sboyd@kernel.org Tested-by: Stephen Boyd swboyd@chromium.org Reviewed-by: Jordan Crouse jcrouse@codeaurora.org Signed-off-by: Rob Clark robdclark@chromium.org Signed-off-by: Sean Paul seanpaul@chromium.org Link: https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdcla... Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/gpu/drm/msm/msm_gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index 644faf3ae93a3..055859095cf01 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -104,7 +104,7 @@ static struct page **get_pages(struct drm_gem_object *obj) * because display controller, GPU, etc. are not coherent: */ if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) - dma_map_sg(dev->dev, msm_obj->sgt->sgl, + dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl, msm_obj->sgt->nents, DMA_BIDIRECTIONAL); }
@@ -120,7 +120,7 @@ static void put_pages(struct drm_gem_object *obj) * because display controller, GPU, etc. are not coherent: */ if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) - dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl, + dma_sync_sg_for_cpu(obj->dev->dev, msm_obj->sgt->sgl, msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
if (msm_obj->sgt)
From: Geert Uytterhoeven geert+renesas@glider.be
Commit 372e722ea4dd4ca1 ("gpiolib: use descriptors internally") renamed the functions to use a "gpiod" prefix, and commit 79a9becda8940deb ("gpiolib: export descriptor-based GPIO interface") introduced the "raw" variants, but both changes forgot to update the comments.
Readd a similar reference to gpiod_set_value(), which was accidentally removed by commit 1e77fc82110ac36f ("gpio: Add missing open drain/source handling to gpiod_set_value_cansleep()").
Signed-off-by: Geert Uytterhoeven geert+renesas@glider.be Link: https://lore.kernel.org/r/20190701142738.25219-1-geert+renesas@glider.be Signed-off-by: Linus Walleij linus.walleij@linaro.org Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/gpio/gpiolib.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 503405d32d240..3369dcc230e58 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1304,7 +1304,7 @@ int gpiod_get_raw_value(const struct gpio_desc *desc) { if (!desc) return 0; - /* Should be using gpio_get_value_cansleep() */ + /* Should be using gpiod_get_raw_value_cansleep() */ WARN_ON(desc->chip->can_sleep); return _gpiod_get_raw_value(desc); } @@ -1325,7 +1325,7 @@ int gpiod_get_value(const struct gpio_desc *desc) int value; if (!desc) return 0; - /* Should be using gpio_get_value_cansleep() */ + /* Should be using gpiod_get_value_cansleep() */ WARN_ON(desc->chip->can_sleep);
value = _gpiod_get_raw_value(desc); @@ -1501,7 +1501,7 @@ void gpiod_set_raw_value(struct gpio_desc *desc, int value) { if (!desc) return; - /* Should be using gpio_set_value_cansleep() */ + /* Should be using gpiod_set_raw_value_cansleep() */ WARN_ON(desc->chip->can_sleep); _gpiod_set_raw_value(desc, value); } @@ -1522,7 +1522,7 @@ void gpiod_set_value(struct gpio_desc *desc, int value) { if (!desc) return; - /* Should be using gpio_set_value_cansleep() */ + /* Should be using gpiod_set_value_cansleep() */ WARN_ON(desc->chip->can_sleep); if (test_bit(FLAG_ACTIVE_LOW, &desc->flags)) value = !value;
On Thu, Apr 23, 2020 at 09:40:00PM +0100, Lee Jones wrote:
From: Geert Uytterhoeven geert+renesas@glider.be
Commit 372e722ea4dd4ca1 ("gpiolib: use descriptors internally") renamed the functions to use a "gpiod" prefix, and commit 79a9becda8940deb ("gpiolib: export descriptor-based GPIO interface") introduced the "raw" variants, but both changes forgot to update the comments.
Readd a similar reference to gpiod_set_value(), which was accidentally removed by commit 1e77fc82110ac36f ("gpio: Add missing open drain/source handling to gpiod_set_value_cansleep()").
Signed-off-by: Geert Uytterhoeven geert+renesas@glider.be Link: https://lore.kernel.org/r/20190701142738.25219-1-geert+renesas@glider.be Signed-off-by: Linus Walleij linus.walleij@linaro.org Signed-off-by: Lee Jones lee.jones@linaro.org
drivers/gpio/gpiolib.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
What is the upstream git commit id for this patch? Please add it and resend.
thanks,
greg k-h
[ Upstream commit 3285170f28a850638794cdfe712eb6d93e51e706 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451 __iommu_dma_unmap+0xb8/0xc0 Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo cfg80211 videobuf2_vmalloc videobuf2_memops vide CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: G W 5.2.0-rc5-next-20190619+ #2317 Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018 Workqueue: msm msm_gem_free_work [msm] pstate: 80c00005 (Nzcv daif +PAN +UAO) pc : __iommu_dma_unmap+0xb8/0xc0 lr : __iommu_dma_unmap+0x54/0xc0 sp : ffff0000119abce0 x29: ffff0000119abce0 x28: 0000000000000000 x27: ffff8001f9946648 x26: ffff8001ec271068 x25: 0000000000000000 x24: ffff8001ea3580a8 x23: ffff8001f95ba010 x22: ffff80018e83ba88 x21: ffff8001e548f000 x20: fffffffffffff000 x19: 0000000000001000 x18: 00000000c00001fe x17: 0000000000000000 x16: 0000000000000000 x15: ffff000015b70068 x14: 0000000000000005 x13: 0003142cc1be1768 x12: 0000000000000001 x11: ffff8001f6de9100 x10: 0000000000000009 x9 : ffff000015b78000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : fffffffffffff000 x5 : 0000000000000fff x4 : ffff00001065dbc8 x3 : 000000000000000d x2 : 0000000000001000 x1 : fffffffffffff000 x0 : 0000000000000000 Call trace: __iommu_dma_unmap+0xb8/0xc0 iommu_dma_unmap_sg+0x98/0xb8 put_pages+0x5c/0xf0 [msm] msm_gem_free_work+0x10c/0x150 [msm] process_one_work+0x1e0/0x330 worker_thread+0x40/0x438 kthread+0x12c/0x130 ret_from_fork+0x10/0x18 ---[ end trace afc0dc5ab81a06bf ]---
Not quite sure what triggered that, but we really shouldn't be abusing dma_{map,unmap}_sg() for cache maint.
Cc: Stephen Boyd sboyd@kernel.org Tested-by: Stephen Boyd swboyd@chromium.org Reviewed-by: Jordan Crouse jcrouse@codeaurora.org Signed-off-by: Rob Clark robdclark@chromium.org Signed-off-by: Sean Paul seanpaul@chromium.org Link: https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdcla... Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/gpu/drm/msm/msm_gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index 644faf3ae93a3..055859095cf01 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -104,7 +104,7 @@ static struct page **get_pages(struct drm_gem_object *obj) * because display controller, GPU, etc. are not coherent: */ if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) - dma_map_sg(dev->dev, msm_obj->sgt->sgl, + dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl, msm_obj->sgt->nents, DMA_BIDIRECTIONAL); }
@@ -120,7 +120,7 @@ static void put_pages(struct drm_gem_object *obj) * because display controller, GPU, etc. are not coherent: */ if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) - dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl, + dma_sync_sg_for_cpu(obj->dev->dev, msm_obj->sgt->sgl, msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
if (msm_obj->sgt)
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 {
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
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
From: Geert Uytterhoeven
Sent: 13 May 2020 10:49
...
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...
Interesting thought. Could the devm 'header' be put right at the end of the kmalloc() buffer?
Then the driver would be given aligned address.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Hi David,
On Wed, May 13, 2020 at 12:10 PM David Laight David.Laight@aculab.com wrote:
From: Geert Uytterhoeven
Sent: 13 May 2020 10:49
...
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...
Interesting thought. Could the devm 'header' be put right at the end of the kmalloc() buffer?
Then the driver would be given aligned address.
Yes, if the header is extended to contain the real start address of the allocated block.
Gr{oetje,eeting}s,
Geert
Hi David,
On Wed, May 13, 2020 at 1:05 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Wed, May 13, 2020 at 12:10 PM David Laight David.Laight@aculab.com wrote:
From: Geert Uytterhoeven
Sent: 13 May 2020 10:49
...
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...
Interesting thought. Could the devm 'header' be put right at the end of the kmalloc() buffer?
Then the driver would be given aligned address.
Yes, if the header is extended to contain the real start address of the allocated block.
But that would break explicit freeing through devm_kfree(), as that is passed a pointer to the payload, not the header.
Gr{oetje,eeting}s,
Geert
From: Geert Uytterhoeven
Sent: 13 May 2020 12:07 Hi David,
On Wed, May 13, 2020 at 1:05 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Wed, May 13, 2020 at 12:10 PM David Laight David.Laight@aculab.com wrote:
From: Geert Uytterhoeven
Sent: 13 May 2020 10:49
...
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...
Interesting thought. Could the devm 'header' be put right at the end of the kmalloc() buffer?
Then the driver would be given aligned address.
Yes, if the header is extended to contain the real start address of the allocated block.
But that would break explicit freeing through devm_kfree(), as that is passed a pointer to the payload, not the header.
There is a function that gives the full size of memory that kmalloc() returns. That can be used to find the end and hence the header.
I don't think you can find the base/size from an address within the buffer - so a length and/or pointer is needed to find the start.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Hi David,
On Wed, May 13, 2020 at 2:37 PM David Laight David.Laight@aculab.com wrote:
From: Geert Uytterhoeven
On Wed, May 13, 2020 at 1:05 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Wed, May 13, 2020 at 12:10 PM David Laight David.Laight@aculab.com wrote:
From: Geert Uytterhoeven
Sent: 13 May 2020 10:49
...
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...
Interesting thought. Could the devm 'header' be put right at the end of the kmalloc() buffer?
Then the driver would be given aligned address.
Yes, if the header is extended to contain the real start address of the allocated block.
But that would break explicit freeing through devm_kfree(), as that is passed a pointer to the payload, not the header.
There is a function that gives the full size of memory that kmalloc() returns. That can be used to find the end and hence the header.
Do you know the name of the function?
I don't think you can find the base/size from an address within the buffer - so a length and/or pointer is needed to find the start.
If that's really possible, then we can finally fix this in a more ememory-efficient way.
Thanks!
Gr{oetje,eeting}s,
Geert
From: Geert Uytterhoeven
Sent: 13 May 2020 14:26 Hi David,
On Wed, May 13, 2020 at 2:37 PM David Laight David.Laight@aculab.com wrote:
From: Geert Uytterhoeven
On Wed, May 13, 2020 at 1:05 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Wed, May 13, 2020 at 12:10 PM David Laight David.Laight@aculab.com wrote:
From: Geert Uytterhoeven
Sent: 13 May 2020 10:49
...
> 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...
Interesting thought. Could the devm 'header' be put right at the end of the kmalloc() buffer?
Then the driver would be given aligned address.
Yes, if the header is extended to contain the real start address of the allocated block.
But that would break explicit freeing through devm_kfree(), as that is passed a pointer to the payload, not the header.
There is a function that gives the full size of memory that kmalloc() returns. That can be used to find the end and hence the header.
Do you know the name of the function?
ksize() - used by the skb allocating code.
I don't know how the all the allocators behave. Some might be adding a header anyway - which might actually have space it in that devm_alloc could use.
OTOH I've seen kernel memory allocators that (effectively) put the index of the pool into the page table. They need no red tape at all.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Wed, May 13, 2020 at 10:10:03AM +0000, David Laight wrote:
From: Geert Uytterhoeven
Sent: 13 May 2020 10:49
...
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...
Interesting thought. Could the devm 'header' be put right at the end of the kmalloc() buffer?
https://lkml.kernel.org/r/20191220140655.GN2827@hirez.programming.kicks-ass....
From: Peter Zijlstra
Sent: 13 May 2020 14:36
On Wed, May 13, 2020 at 10:10:03AM +0000, David Laight wrote:
From: Geert Uytterhoeven
Sent: 13 May 2020 10:49
...
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...
Interesting thought. Could the devm 'header' be put right at the end of the kmalloc() buffer?
https://lkml.kernel.org/r/20191220140655.GN2827@hirez.programming.kicks-ass....
All the way around the loop.....
ISTR there have also been issues with one of the kmalloc() implementations adding a header to the memory block. Didn't it generate 4n+2 aligned buffers on m68k - breaking code that tried to use the two lower bits of an address.
If one of the kmalloc()s behaves like that it ought to be possible for devm_alloc() to use the spare space in the same cache line??
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
From: Markus Elfring elfring@users.sourceforge.net
[ Upstream commit 0108aab1161532c9b62a0d05b8115f4d0b529831 ]
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring elfring@users.sourceforge.net Reviewed-by: Christophe Leroy christophe.leroy@c-s.fr Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/crypto/talitos.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index 1c8857e7db894..f3d0a33f4ddb4 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -1287,7 +1287,6 @@ static struct talitos_edesc *talitos_edesc_alloc(struct device *dev, if (iv_dma) dma_unmap_single(dev, iv_dma, ivsize, DMA_TO_DEVICE);
- dev_err(dev, "could not allocate edescriptor\n"); return ERR_PTR(-ENOMEM); }
On Thu, Apr 23, 2020 at 09:40:02PM +0100, Lee Jones wrote:
From: Markus Elfring elfring@users.sourceforge.net
[ Upstream commit 0108aab1161532c9b62a0d05b8115f4d0b529831 ]
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring elfring@users.sourceforge.net Reviewed-by: Christophe Leroy christophe.leroy@c-s.fr Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Signed-off-by: Lee Jones lee.jones@linaro.org
drivers/crypto/talitos.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index 1c8857e7db894..f3d0a33f4ddb4 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -1287,7 +1287,6 @@ static struct talitos_edesc *talitos_edesc_alloc(struct device *dev, if (iv_dma) dma_unmap_single(dev, iv_dma, ivsize, DMA_TO_DEVICE);
dev_err(dev, "could not allocate edescriptor\n");
Not really stable material, also missing from 4.9 and 4.14 trees.
On Wed, 13 May 2020, Greg KH wrote:
On Thu, Apr 23, 2020 at 09:40:02PM +0100, Lee Jones wrote:
From: Markus Elfring elfring@users.sourceforge.net
[ Upstream commit 0108aab1161532c9b62a0d05b8115f4d0b529831 ]
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring elfring@users.sourceforge.net Reviewed-by: Christophe Leroy christophe.leroy@c-s.fr Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Signed-off-by: Lee Jones lee.jones@linaro.org
drivers/crypto/talitos.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index 1c8857e7db894..f3d0a33f4ddb4 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -1287,7 +1287,6 @@ static struct talitos_edesc *talitos_edesc_alloc(struct device *dev, if (iv_dma) dma_unmap_single(dev, iv_dma, ivsize, DMA_TO_DEVICE);
dev_err(dev, "could not allocate edescriptor\n");Not really stable material, also missing from 4.9 and 4.14 trees.
This doesn't apply to 4.9 or 4.14.
Looks like it was already removed in:
4.9: 47fbc54bbe52709fbdc50f5578acf964962942b2 4.14: c3f5e4efce3e2ece7f31826a14849e60d342bde1
From: Joe Moriarty joe.moriarty@oracle.com
[ Upstream commit 22a07038c0eaf4d1315a493ce66dcd255accba19 ]
The Parfait (version 2.1.0) static code analysis tool found the following NULL pointer derefernce problem.
- drivers/gpu/drm/drm_dp_mst_topology.c The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt() could result in a NULL pointer being returned to port->mstb due to a failure to allocate memory for port->mstb.
Signed-off-by: Joe Moriarty joe.moriarty@oracle.com Reviewed-by: Steven Sistare steven.sistare@oracle.com Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch Link: https://patchwork.freedesktop.org/patch/msgid/20180212195144.98323-3-joe.mor... Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index f5229b083f8ea..abf5bd09de33b 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -1036,10 +1036,12 @@ static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port *port) lct = drm_dp_calculate_rad(port, rad);
port->mstb = drm_dp_add_mst_branch_device(lct, rad); - port->mstb->mgr = port->mgr; - port->mstb->port_parent = port; + if (port->mstb) { + port->mstb->mgr = port->mgr; + port->mstb->port_parent = port;
- send_link = true; + send_link = true; + } break; } return send_link;
On Thu, Apr 23, 2020 at 09:40:03PM +0100, Lee Jones wrote:
From: Joe Moriarty joe.moriarty@oracle.com
[ Upstream commit 22a07038c0eaf4d1315a493ce66dcd255accba19 ]
The Parfait (version 2.1.0) static code analysis tool found the following NULL pointer derefernce problem.
- drivers/gpu/drm/drm_dp_mst_topology.c
The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt() could result in a NULL pointer being returned to port->mstb due to a failure to allocate memory for port->mstb.
Signed-off-by: Joe Moriarty joe.moriarty@oracle.com Reviewed-by: Steven Sistare steven.sistare@oracle.com Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch Link: https://patchwork.freedesktop.org/patch/msgid/20180212195144.98323-3-joe.mor... Signed-off-by: Lee Jones lee.jones@linaro.org
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
Already in the 4.4.220 release.
From: Geert Uytterhoeven geert+renesas@glider.be
[ Upstream commit 4c8326d5ebb0de3191e98980c80ab644026728d0 ]
When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, matching the data types.
Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs.
clk_core.rate and .accuracy are "unsigned long", hence casting their addresses to "u32 *" exposed the wrong halves on big-endian 64-bit systems. Fix this by using debugfs_create_ulong() instead.
Octal permissions are preferred, as they are easier to read than symbolic permissions. Hence replace "S_IRUGO" by "0444" throughout.
Signed-off-by: Geert Uytterhoeven geert+renesas@glider.be [sboyd@codeaurora.org: Squash the octal change in too] Signed-off-by: Stephen Boyd sboyd@codeaurora.org Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/clk/clk.c | 30 ++++++++++++++---------------- 1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 53c068f90b376..0654dbf86364f 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -2121,18 +2121,16 @@ static int clk_debug_create_one(struct clk_core *core, struct dentry *pdentry)
core->dentry = d;
- d = debugfs_create_u32("clk_rate", S_IRUGO, core->dentry, - (u32 *)&core->rate); + d = debugfs_create_ulong("clk_rate", 0444, core->dentry, &core->rate); if (!d) goto err_out;
- d = debugfs_create_u32("clk_accuracy", S_IRUGO, core->dentry, - (u32 *)&core->accuracy); + d = debugfs_create_ulong("clk_accuracy", 0444, core->dentry, + &core->accuracy); if (!d) goto err_out;
- d = debugfs_create_u32("clk_phase", S_IRUGO, core->dentry, - (u32 *)&core->phase); + d = debugfs_create_u32("clk_phase", 0444, core->dentry, &core->phase); if (!d) goto err_out;
@@ -2141,18 +2139,18 @@ static int clk_debug_create_one(struct clk_core *core, struct dentry *pdentry) if (!d) goto err_out;
- d = debugfs_create_u32("clk_prepare_count", S_IRUGO, core->dentry, - (u32 *)&core->prepare_count); + d = debugfs_create_u32("clk_prepare_count", 0444, core->dentry, + &core->prepare_count); if (!d) goto err_out;
- d = debugfs_create_u32("clk_enable_count", S_IRUGO, core->dentry, - (u32 *)&core->enable_count); + d = debugfs_create_u32("clk_enable_count", 0444, core->dentry, + &core->enable_count); if (!d) goto err_out;
- d = debugfs_create_u32("clk_notifier_count", S_IRUGO, core->dentry, - (u32 *)&core->notifier_count); + d = debugfs_create_u32("clk_notifier_count", 0444, core->dentry, + &core->notifier_count); if (!d) goto err_out;
@@ -2246,22 +2244,22 @@ static int __init clk_debug_init(void) if (!rootdir) return -ENOMEM;
- d = debugfs_create_file("clk_summary", S_IRUGO, rootdir, &all_lists, + d = debugfs_create_file("clk_summary", 0444, rootdir, &all_lists, &clk_summary_fops); if (!d) return -ENOMEM;
- d = debugfs_create_file("clk_dump", S_IRUGO, rootdir, &all_lists, + d = debugfs_create_file("clk_dump", 0444, rootdir, &all_lists, &clk_dump_fops); if (!d) return -ENOMEM;
- d = debugfs_create_file("clk_orphan_summary", S_IRUGO, rootdir, + d = debugfs_create_file("clk_orphan_summary", 0444, rootdir, &orphan_list, &clk_summary_fops); if (!d) return -ENOMEM;
- d = debugfs_create_file("clk_orphan_dump", S_IRUGO, rootdir, + d = debugfs_create_file("clk_orphan_dump", 0444, rootdir, &orphan_list, &clk_dump_fops); if (!d) return -ENOMEM;
On Thu, Apr 23, 2020 at 09:40:04PM +0100, Lee Jones wrote:
From: Geert Uytterhoeven geert+renesas@glider.be
[ Upstream commit 4c8326d5ebb0de3191e98980c80ab644026728d0 ]
When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, matching the data types.
Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs.
clk_core.rate and .accuracy are "unsigned long", hence casting their addresses to "u32 *" exposed the wrong halves on big-endian 64-bit systems. Fix this by using debugfs_create_ulong() instead.
Octal permissions are preferred, as they are easier to read than symbolic permissions. Hence replace "S_IRUGO" by "0444" throughout.
Signed-off-by: Geert Uytterhoeven geert+renesas@glider.be [sboyd@codeaurora.org: Squash the octal change in too] Signed-off-by: Stephen Boyd sboyd@codeaurora.org Signed-off-by: Lee Jones lee.jones@linaro.org
drivers/clk/clk.c | 30 ++++++++++++++---------------- 1 file changed, 14 insertions(+), 16 deletions(-)
What about 4.9?
I'm going to stop here and wait for a fixed up series of this, and any newer kernels that need the patches as well.
thanks,
greg k-h
On Wed, 13 May 2020, Greg KH wrote:
On Thu, Apr 23, 2020 at 09:40:04PM +0100, Lee Jones wrote:
From: Geert Uytterhoeven geert+renesas@glider.be
[ Upstream commit 4c8326d5ebb0de3191e98980c80ab644026728d0 ]
When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, matching the data types.
Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs.
clk_core.rate and .accuracy are "unsigned long", hence casting their addresses to "u32 *" exposed the wrong halves on big-endian 64-bit systems. Fix this by using debugfs_create_ulong() instead.
Octal permissions are preferred, as they are easier to read than symbolic permissions. Hence replace "S_IRUGO" by "0444" throughout.
Signed-off-by: Geert Uytterhoeven geert+renesas@glider.be [sboyd@codeaurora.org: Squash the octal change in too] Signed-off-by: Stephen Boyd sboyd@codeaurora.org Signed-off-by: Lee Jones lee.jones@linaro.org
drivers/clk/clk.c | 30 ++++++++++++++---------------- 1 file changed, 14 insertions(+), 16 deletions(-)
What about 4.9?
I sent this for v4.9 on the 22nd April.
https://www.spinics.net/lists/stable/msg382001.html
I'm going to stop here and wait for a fixed up series of this, and any newer kernels that need the patches as well.
thanks,
greg k-h
From: Will Deacon will.deacon@arm.com
[ Upstream commit a25ffd3a6302a67814280274d8f1aa4ae2ea4b59 ]
Printing raw pointer values in backtraces has potential security implications and are of questionable value anyway.
This patch follows x86's lead and removes the "Exception stack:" dump from kernel backtraces, as well as converting PC/LR values to symbols such as "sysrq_handle_crash+0x20/0x30".
Tested-by: Laura Abbott labbott@redhat.com Signed-off-by: Will Deacon will.deacon@arm.com Signed-off-by: Lee Jones lee.jones@linaro.org --- arch/arm64/kernel/process.c | 9 +++-- arch/arm64/kernel/traps.c | 72 ++----------------------------------- 2 files changed, 7 insertions(+), 74 deletions(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c index 10d6627673cbf..2733b04900d1c 100644 --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -180,11 +180,10 @@ void __show_regs(struct pt_regs *regs) }
show_regs_print_info(KERN_DEFAULT); - print_symbol("PC is at %s\n", instruction_pointer(regs)); - print_symbol("LR is at %s\n", lr); - printk("pc : [<%016llx>] lr : [<%016llx>] pstate: %08llx\n", - regs->pc, lr, regs->pstate); - printk("sp : %016llx\n", sp); + print_symbol("pc : %s\n", regs->pc); + print_symbol("lr : %s\n", lr); + printk("sp : %016llx pstate : %08llx\n", sp, regs->pstate); + for (i = top_reg; i >= 0; i--) { printk("x%-2d: %016llx ", i, regs->regs[i]); if (i % 2 == 0) diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index 02710f99c1374..0cc78d60dac33 100644 --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -51,63 +51,9 @@ static const char *handler[]= {
int show_unhandled_signals = 0;
-/* - * Dump out the contents of some memory nicely... - */ -static void dump_mem(const char *lvl, const char *str, unsigned long bottom, - unsigned long top, bool compat) -{ - unsigned long first; - mm_segment_t fs; - int i; - unsigned int width = compat ? 4 : 8; - - /* - * We need to switch to kernel mode so that we can use __get_user - * to safely read from kernel space. - */ - fs = get_fs(); - set_fs(KERNEL_DS); - - printk("%s%s(0x%016lx to 0x%016lx)\n", lvl, str, bottom, top); - - for (first = bottom & ~31; first < top; first += 32) { - unsigned long p; - char str[sizeof(" 12345678") * 8 + 1]; - - memset(str, ' ', sizeof(str)); - str[sizeof(str) - 1] = '\0'; - - for (p = first, i = 0; i < (32 / width) - && p < top; i++, p += width) { - if (p >= bottom && p < top) { - unsigned long val; - - if (width == 8) { - if (__get_user(val, (unsigned long *)p) == 0) - sprintf(str + i * 17, " %016lx", val); - else - sprintf(str + i * 17, " ????????????????"); - } else { - if (__get_user(val, (unsigned int *)p) == 0) - sprintf(str + i * 9, " %08lx", val); - else - sprintf(str + i * 9, " ????????"); - } - } - } - printk("%s%04lx:%s\n", lvl, first & 0xffff, str); - } - - set_fs(fs); -} - static void dump_backtrace_entry(unsigned long where) { - /* - * Note that 'where' can have a physical address, but it's not handled. - */ - print_ip_sym(where); + printk(" %pS\n", (void *)where); }
static void __dump_instr(const char *lvl, struct pt_regs *regs) @@ -170,20 +116,11 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk) }
pr_emerg("Call trace:\n"); - while (1) { + do { unsigned long where = frame.pc; - unsigned long stack; - int ret;
dump_backtrace_entry(where); - ret = unwind_frame(&frame); - if (ret < 0) - break; - stack = frame.sp; - if (in_exception_text(where)) - dump_mem("", "Exception stack", stack, - stack + sizeof(struct pt_regs), false); - } + } while (!unwind_frame(&frame)); }
void show_stack(struct task_struct *tsk, unsigned long *sp) @@ -220,9 +157,6 @@ static int __die(const char *str, int err, struct thread_info *thread, TASK_COMM_LEN, tsk->comm, task_pid_nr(tsk), thread + 1);
if (!user_mode(regs) || in_interrupt()) { - dump_mem(KERN_EMERG, "Stack: ", regs->sp, - THREAD_SIZE + (unsigned long)task_stack_page(tsk), - compat_user_mode(regs)); dump_backtrace(regs, tsk); dump_instr(KERN_EMERG, regs); }
From: Yangtao Li tiny.windzz@gmail.com
[ Upstream commit 20d8e8611eb0596047fd4389be7a7203a883b9bf ]
of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. This place is not doing this, so fix it.
Signed-off-by: Yangtao Li tiny.windzz@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/tty/serial/sunsu.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/sunsu.c b/drivers/tty/serial/sunsu.c index e124d2e88996f..8db64282260fb 100644 --- a/drivers/tty/serial/sunsu.c +++ b/drivers/tty/serial/sunsu.c @@ -1393,22 +1393,32 @@ static inline struct console *SUNSU_CONSOLE(void) static enum su_type su_get_type(struct device_node *dp) { struct device_node *ap = of_find_node_by_path("/aliases"); + enum su_type rc = SU_PORT_PORT;
if (ap) { + struct device_node *tmp; const char *keyb = of_get_property(ap, "keyboard", NULL); const char *ms = of_get_property(ap, "mouse", NULL);
if (keyb) { - if (dp == of_find_node_by_path(keyb)) - return SU_PORT_KBD; + tmp = of_find_node_by_path(keyb); + if (tmp && dp == tmp){ + rc = SU_PORT_KBD; + goto out; + } } if (ms) { - if (dp == of_find_node_by_path(ms)) - return SU_PORT_MS; + tmp = of_find_node_by_path(ms); + if (tmp && dp == tmp){ + rc = SU_PORT_MS; + goto out; + } } }
- return SU_PORT_PORT; +out: + of_node_put(ap); + return rc; }
static int su_probe(struct platform_device *op)
On Thu, Apr 23, 2020 at 09:40:06PM +0100, Lee Jones wrote:
From: Yangtao Li tiny.windzz@gmail.com
[ Upstream commit 20d8e8611eb0596047fd4389be7a7203a883b9bf ]
of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. This place is not doing this, so fix it.
Signed-off-by: Yangtao Li tiny.windzz@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Lee Jones lee.jones@linaro.org
drivers/tty/serial/sunsu.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-)
What about 4.9.y, 4.14.y, and 4.19.y for this?
greg k-h
On Wed, 06 May 2020, Greg Kroah-Hartman wrote:
On Thu, Apr 23, 2020 at 09:40:06PM +0100, Lee Jones wrote:
From: Yangtao Li tiny.windzz@gmail.com
[ Upstream commit 20d8e8611eb0596047fd4389be7a7203a883b9bf ]
of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. This place is not doing this, so fix it.
Signed-off-by: Yangtao Li tiny.windzz@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Lee Jones lee.jones@linaro.org
drivers/tty/serial/sunsu.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-)
What about 4.9.y, 4.14.y, and 4.19.y for this?
Yes, according to my results file, it should have been applied:
stable/results/vendor-sony-xperia-aosp-LA.UM.7.1.r1-phase-2.txt 20d8e8611eb0 stable-linux-4.4.y stable-linux-4.9.y \ stable-linux-4.14.y stable-linux-4.19.y
I can't think why it was dropped. Perhaps it didn't apply, although I usually fight to get them applied if at all possible.
Are you able to apply it?
From: Hamad Kadmany hkadmany@codeaurora.org
[ Upstream commit 6ccae584014ef7074359eb4151086beef66ecfa9 ]
Firmware ready event may take longer than current timeout in some scenarios, for example with multiple RFs connected where each requires an initial calibration.
Increase the timeout to support these scenarios.
Signed-off-by: Hamad Kadmany hkadmany@codeaurora.org Signed-off-by: Maya Erez merez@codeaurora.org Signed-off-by: Kalle Valo kvalo@codeaurora.org Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/net/wireless/ath/wil6210/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wil6210/main.c b/drivers/net/wireless/ath/wil6210/main.c index f09fafaaaf1a3..c377937aae1c4 100644 --- a/drivers/net/wireless/ath/wil6210/main.c +++ b/drivers/net/wireless/ath/wil6210/main.c @@ -741,7 +741,7 @@ static void wil_bl_crash_info(struct wil6210_priv *wil, bool is_err)
static int wil_wait_for_fw_ready(struct wil6210_priv *wil) { - ulong to = msecs_to_jiffies(1000); + ulong to = msecs_to_jiffies(2000); ulong left = wait_for_completion_timeout(&wil->wmi_ready, to);
if (0 == left) {
From: Dedy Lansky dlansky@codeaurora.org
[ Upstream commit 6d9eb7ebae3d7e951bc0999235ae7028eb4cae4f ]
For negative temperatures, "temp" debugfs is showing wrong values. Use signed types so proper calculations is done for sub zero temperatures.
Signed-off-by: Dedy Lansky dlansky@codeaurora.org Signed-off-by: Maya Erez merez@codeaurora.org Signed-off-by: Kalle Valo kvalo@codeaurora.org Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/net/wireless/ath/wil6210/debugfs.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c b/drivers/net/wireless/ath/wil6210/debugfs.c index 97bc186f97282..2da03d69ed42e 100644 --- a/drivers/net/wireless/ath/wil6210/debugfs.c +++ b/drivers/net/wireless/ath/wil6210/debugfs.c @@ -1088,7 +1088,7 @@ static const struct file_operations fops_ssid = { };
/*---------temp------------*/ -static void print_temp(struct seq_file *s, const char *prefix, u32 t) +static void print_temp(struct seq_file *s, const char *prefix, s32 t) { switch (t) { case 0: @@ -1096,7 +1096,8 @@ static void print_temp(struct seq_file *s, const char *prefix, u32 t) seq_printf(s, "%s N/A\n", prefix); break; default: - seq_printf(s, "%s %d.%03d\n", prefix, t / 1000, t % 1000); + seq_printf(s, "%s %s%d.%03d\n", prefix, (t < 0 ? "-" : ""), + abs(t / 1000), abs(t % 1000)); break; } } @@ -1104,7 +1105,7 @@ static void print_temp(struct seq_file *s, const char *prefix, u32 t) static int wil_temp_debugfs_show(struct seq_file *s, void *data) { struct wil6210_priv *wil = s->private; - u32 t_m, t_r; + s32 t_m, t_r; int rc = wmi_get_temperature(wil, &t_m, &t_r);
if (rc) {
From: Subhash Jadavani subhashj@codeaurora.org
[ Upstream commit 69a6fff068567469c0ef1156ae5ac8d3d71701f0 ]
UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION is only applicable for QCOM UFS host controller version 2.x.y and this has been fixed from version 3.x.y onwards, hence this change removes this quirk for version 3.x.y onwards.
[mkp: applied by hand]
Signed-off-by: Subhash Jadavani subhashj@codeaurora.org Signed-off-by: Asutosh Das asutoshd@codeaurora.org Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/scsi/ufs/ufs-qcom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c index 4b82c3765e013..2b779a55f6999 100644 --- a/drivers/scsi/ufs/ufs-qcom.c +++ b/drivers/scsi/ufs/ufs-qcom.c @@ -1032,7 +1032,7 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba) hba->quirks |= UFSHCD_QUIRK_BROKEN_LCC; }
- if (host->hw_ver.major >= 0x2) { + if (host->hw_ver.major == 0x2) { hba->quirks |= UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION;
if (!ufs_qcom_cap_qunipro(host))
From: Dedy Lansky dlansky@codeaurora.org
[ Upstream commit 3d6b72729cc2933906de8d2c602ae05e920b2122 ]
wil_err inside wil_rx_refill can flood the log buffer. Replace it with wil_err_ratelimited.
Signed-off-by: Dedy Lansky dlansky@codeaurora.org Signed-off-by: Maya Erez merez@codeaurora.org Signed-off-by: Kalle Valo kvalo@codeaurora.org Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/net/wireless/ath/wil6210/txrx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/txrx.c b/drivers/net/wireless/ath/wil6210/txrx.c index 3bc9bc0efbacc..af436292190b1 100644 --- a/drivers/net/wireless/ath/wil6210/txrx.c +++ b/drivers/net/wireless/ath/wil6210/txrx.c @@ -538,8 +538,8 @@ static int wil_rx_refill(struct wil6210_priv *wil, int count) v->swtail = next_tail) { rc = wil_vring_alloc_skb(wil, v, v->swtail, headroom); if (unlikely(rc)) { - wil_err(wil, "Error %d in wil_rx_refill[%d]\n", - rc, v->swtail); + wil_err_ratelimited(wil, "Error %d in rx refill[%d]\n", + rc, v->swtail); break; } }
From: Mohit Aggarwal maggarwa@codeaurora.org
[ Upstream commit 83220bf38b77a830f8e62ab1a0d0408304f9b966 ]
In order to set time in rtc, need to disable rtc hw before writing into rtc registers.
Also fixes disabling of alarm while setting rtc time.
Signed-off-by: Mohit Aggarwal maggarwa@codeaurora.org Signed-off-by: Alexandre Belloni alexandre.belloni@bootlin.com Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/rtc/rtc-pm8xxx.c | 49 +++++++++++++++++++++++++++++++--------- 1 file changed, 38 insertions(+), 11 deletions(-)
diff --git a/drivers/rtc/rtc-pm8xxx.c b/drivers/rtc/rtc-pm8xxx.c index a0dae6271ff64..cd4434cca877c 100644 --- a/drivers/rtc/rtc-pm8xxx.c +++ b/drivers/rtc/rtc-pm8xxx.c @@ -74,16 +74,18 @@ struct pm8xxx_rtc { /* * Steps to write the RTC registers. * 1. Disable alarm if enabled. - * 2. Write 0x00 to LSB. - * 3. Write Byte[1], Byte[2], Byte[3] then Byte[0]. - * 4. Enable alarm if disabled in step 1. + * 2. Disable rtc if enabled. + * 3. Write 0x00 to LSB. + * 4. Write Byte[1], Byte[2], Byte[3] then Byte[0]. + * 5. Enable rtc if disabled in step 2. + * 6. Enable alarm if disabled in step 1. */ static int pm8xxx_rtc_set_time(struct device *dev, struct rtc_time *tm) { int rc, i; unsigned long secs, irq_flags; - u8 value[NUM_8_BIT_RTC_REGS], alarm_enabled = 0; - unsigned int ctrl_reg; + u8 value[NUM_8_BIT_RTC_REGS], alarm_enabled = 0, rtc_disabled = 0; + unsigned int ctrl_reg, rtc_ctrl_reg; struct pm8xxx_rtc *rtc_dd = dev_get_drvdata(dev); const struct pm8xxx_rtc_regs *regs = rtc_dd->regs;
@@ -92,23 +94,38 @@ static int pm8xxx_rtc_set_time(struct device *dev, struct rtc_time *tm)
rtc_tm_to_time(tm, &secs);
+ dev_dbg(dev, "Seconds value to be written to RTC = %lu\n", secs); + for (i = 0; i < NUM_8_BIT_RTC_REGS; i++) { value[i] = secs & 0xFF; secs >>= 8; }
- dev_dbg(dev, "Seconds value to be written to RTC = %lu\n", secs); - spin_lock_irqsave(&rtc_dd->ctrl_reg_lock, irq_flags);
- rc = regmap_read(rtc_dd->regmap, regs->ctrl, &ctrl_reg); + rc = regmap_read(rtc_dd->regmap, regs->alarm_ctrl, &ctrl_reg); if (rc) goto rtc_rw_fail;
if (ctrl_reg & regs->alarm_en) { alarm_enabled = 1; ctrl_reg &= ~regs->alarm_en; - rc = regmap_write(rtc_dd->regmap, regs->ctrl, ctrl_reg); + rc = regmap_write(rtc_dd->regmap, regs->alarm_ctrl, ctrl_reg); + if (rc) { + dev_err(dev, "Write to RTC Alarm control register failed\n"); + goto rtc_rw_fail; + } + } + + /* Disable RTC H/w before writing on RTC register */ + rc = regmap_read(rtc_dd->regmap, regs->ctrl, &rtc_ctrl_reg); + if (rc) + goto rtc_rw_fail; + + if (rtc_ctrl_reg & PM8xxx_RTC_ENABLE) { + rtc_disabled = 1; + rtc_ctrl_reg &= ~PM8xxx_RTC_ENABLE; + rc = regmap_write(rtc_dd->regmap, regs->ctrl, rtc_ctrl_reg); if (rc) { dev_err(dev, "Write to RTC control register failed\n"); goto rtc_rw_fail; @@ -137,11 +154,21 @@ static int pm8xxx_rtc_set_time(struct device *dev, struct rtc_time *tm) goto rtc_rw_fail; }
+ /* Enable RTC H/w after writing on RTC register */ + if (rtc_disabled) { + rtc_ctrl_reg |= PM8xxx_RTC_ENABLE; + rc = regmap_write(rtc_dd->regmap, regs->ctrl, rtc_ctrl_reg); + if (rc) { + dev_err(dev, "Write to RTC control register failed\n"); + goto rtc_rw_fail; + } + } + if (alarm_enabled) { ctrl_reg |= regs->alarm_en; - rc = regmap_write(rtc_dd->regmap, regs->ctrl, ctrl_reg); + rc = regmap_write(rtc_dd->regmap, regs->alarm_ctrl, ctrl_reg); if (rc) { - dev_err(dev, "Write to RTC control register failed\n"); + dev_err(dev, "Write to RTC Alarm control register failed\n"); goto rtc_rw_fail; } }
From: Chris Lew clew@codeaurora.org
[ Upstream commit a216000f0140f415cec96129f777b5234c9d142f ]
Endianness can vary in the system, add le32_to_cpu when comparing partition sizes from smem.
Signed-off-by: Chris Lew clew@codeaurora.org Acked-by: Bjorn Andersson bjorn.andersson@linaro.org Signed-off-by: Andy Gross andy.gross@linaro.org Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/soc/qcom/smem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c index 19019aa092e86..a1572075b8acc 100644 --- a/drivers/soc/qcom/smem.c +++ b/drivers/soc/qcom/smem.c @@ -646,7 +646,7 @@ static int qcom_smem_enumerate_partitions(struct qcom_smem *smem, return -EINVAL; }
- if (header->size != entry->size) { + if (le32_to_cpu(header->size) != le32_to_cpu(entry->size)) { dev_err(smem->dev, "Partition %d has invalid size\n", i); return -EINVAL;
From: Rob Herring robh@kernel.org
[ Upstream commit bd82bbf38cbe27f2c65660da801900d71bcc5cc8 ]
The ref counting is broken for OF_DYNAMIC when sysfs is disabled because the kobject initialization is skipped. Only the properties add/remove/update should be skipped for !SYSFS config.
Tested-by: Nicolas Pitre nico@linaro.org Reviewed-by: Frank Rowand frowand.list@gmail.com Acked-by: Grant Likely grant.likely@secretlab.ca Signed-off-by: Rob Herring robh@kernel.org Signed-off-by: Lee Jones lee.jones@linaro.org --- drivers/of/base.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c index 27783223ca5cd..8adffecd710b8 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -167,9 +167,6 @@ int __of_attach_node_sysfs(struct device_node *np) struct property *pp; int rc;
- if (!IS_ENABLED(CONFIG_SYSFS)) - return 0; - if (!of_kset) return 0;
From: Austin Kim austindh.kim@gmail.com
[ Upstream commit 7ea362427c170061b8822dd41bafaa72b3bcb9ad ]
If !area->pages statement is true where memory allocation fails, area is freed.
In this case 'area->pages = pages' should not executed. So move 'area->pages = pages' after if statement.
[akpm@linux-foundation.org: give area->pages the same treatment] Link: http://lkml.kernel.org/r/20190830035716.GA190684@LGEARND20B15 Signed-off-by: Austin Kim austindh.kim@gmail.com Acked-by: Michal Hocko mhocko@suse.com Reviewed-by: Andrew Morton akpm@linux-foundation.org Cc: Uladzislau Rezki (Sony) urezki@gmail.com Cc: Roman Gushchin guro@fb.com Cc: Roman Penyaev rpenyaev@suse.de Cc: Rick Edgecombe rick.p.edgecombe@intel.com Cc: Mike Rapoport rppt@linux.ibm.com Cc: Andrey Ryabinin aryabinin@virtuozzo.com Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Lee Jones lee.jones@linaro.org --- mm/vmalloc.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index c9e6fc6a5fefe..49f15a460a7b3 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -1593,7 +1593,6 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, nr_pages = get_vm_area_size(area) >> PAGE_SHIFT; array_size = (nr_pages * sizeof(struct page *));
- area->nr_pages = nr_pages; /* Please note that the recursion is strictly bounded. */ if (array_size > PAGE_SIZE) { pages = __vmalloc_node(array_size, 1, nested_gfp|__GFP_HIGHMEM, @@ -1602,13 +1601,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, } else { pages = kmalloc_node(array_size, nested_gfp, node); } - area->pages = pages; - if (!area->pages) { + + if (!pages) { remove_vm_area(area->addr); kfree(area); return NULL; }
+ area->pages = pages; + area->nr_pages = nr_pages; + for (i = 0; i < area->nr_pages; i++) { struct page *page;
linux-stable-mirror@lists.linaro.org
-
David Laight -
Geert Uytterhoeven -
Greg KH -
Greg KH -
Greg Kroah-Hartman
-
Lee Jones -
Peter Zijlstra