August 2019 - Linux-stable-mirror

[PATCH v4.4.y, v4.9.y] block: blk_init_allocated_queue() set q->fq as NULL in the fail case

by Guenter Roeck

From: xiao jin <jin.xiao(a)intel.com> commit 54648cf1ec2d7f4b6a71767799c45676a138ca24 upstream We find the memory use-after-free issue in __blk_drain_queue() on the kernel 4.14. After read the latest kernel 4.18-rc6 we think it has the same problem. Memory is allocated for q->fq in the blk_init_allocated_queue(). If the elevator init function called with error return, it will run into the fail case to free the q->fq. Then the __blk_drain_queue() uses the same memory after the free of the q->fq, it will lead to the unpredictable event. The patch is to set q->fq as NULL in the fail case of blk_init_allocated_queue(). Fixes: commit 7c94e1c157a2 ("block: introduce blk_flush_queue to drive flush machinery") Cc: <stable(a)vger.kernel.org> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Reviewed-by: Bart Van Assche <bart.vanassche(a)wdc.com> Signed-off-by: xiao jin <jin.xiao(a)intel.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> [groeck: backport to v4.4.y/v4.9.y (context change)] Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> --- This patch was not applied to v4.4.y and v4.9.y due to a context conflict. See https://lore.kernel.org/stable/1536310209129100@kroah.com/ and https://lore.kernel.org/stable/153631018011582@kroah.com/ for details. It was applied to v4.14.y and to v4.18.y. Please consider applying this backport. It is relevant because it fixes CVE-2018-20856. Thanks, Guenter block/blk-core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/blk-core.c b/block/blk-core.c index 50d77c90070d..7662f97dded6 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -870,6 +870,7 @@ blk_init_allocated_queue(struct request_queue *q, request_fn_proc *rfn, fail: blk_free_flush_queue(q->fq); + q->fq = NULL; return NULL; } EXPORT_SYMBOL(blk_init_allocated_queue); -- 2.7.4

5 years, 4 months

2
1
0 0

[PATCHES] Networking

by David Miller

Please queue up the following networking bug fixes for v4.19 and v5.2 -stable, respectively. Thank you.

5 years, 4 months

2
1
0 0

patch "Revert "kernfs: fix memleak in kernel_ops_readdir()"" added to driver-core-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "kernfs: fix memleak in kernel_ops_readdir()" to my driver-core git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git in the driver-core-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 8097c43bcbec56fbd0788d99e1e236c0e0d4013f Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Thu, 8 Aug 2019 08:39:35 +0200 Subject: Revert "kernfs: fix memleak in kernel_ops_readdir()" This reverts commit cc798c83898ea0a77fcaa1a92afda35c3c3ded74. Tony writes: Somehow this causes a regression in Linux next for me where I'm seeing lots of sysfs entries now missing under /sys/bus/platform/devices. For example, I now only see one .serial entry show up in sysfs. Things work again if I revert commit cc798c83898e ("kernfs: fix memleak inkernel_ops_readdir()"). Any ideas why that would be? Tejun says: Ugh, you're right. It can get double-put cuz ctx->pos is put by release too. So reverting it for now. Reported-by: Tony Lindgren <tony(a)atomide.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Tejun Heo <tj(a)kernel.org> Fixes: cc798c83898e ("kernfs: fix memleak in kernel_ops_readdir()") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/kernfs/dir.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c index 1e98efc2bf6d..a387534c9577 100644 --- a/fs/kernfs/dir.c +++ b/fs/kernfs/dir.c @@ -1684,14 +1684,11 @@ static int kernfs_fop_readdir(struct file *file, struct dir_context *ctx) kernfs_get(pos); mutex_unlock(&kernfs_mutex); - if (unlikely(!dir_emit(ctx, name, len, ino, type))) { - kernfs_put(pos); - goto out; - } + if (!dir_emit(ctx, name, len, ino, type)) + return 0; mutex_lock(&kernfs_mutex); } mutex_unlock(&kernfs_mutex); -out: file->private_data = NULL; ctx->pos = INT_MAX; return 0; -- 2.22.0

5 years, 4 months

1
0
0 0

[PATCH v5 1/2] x86/purgatory: do not use __builtin_memcpy and __builtin_memset

by Nick Desaulniers

Implementing memcpy and memset in terms of __builtin_memcpy and __builtin_memset is problematic. GCC at -O2 will replace calls to the builtins with calls to memcpy and memset (but will generate an inline implementation at -Os). Clang will replace the builtins with these calls regardless of optimization level. $ llvm-objdump -dr arch/x86/purgatory/string.o | tail 0000000000000339 memcpy: 339: 48 b8 00 00 00 00 00 00 00 00 movabsq $0, %rax 000000000000033b: R_X86_64_64 memcpy 343: ff e0 jmpq *%rax 0000000000000345 memset: 345: 48 b8 00 00 00 00 00 00 00 00 movabsq $0, %rax 0000000000000347: R_X86_64_64 memset 34f: ff e0 Such code results in infinite recursion at runtime. This is observed when doing kexec. Instead, reuse an implementation from arch/x86/boot/compressed/string.c if we define warn as a symbol. Also, Clang may lower memcmp's that compare against 0 to bcmp's, so add a small definition, too. See also: commit 5f074f3e192f ("lib/string.c: implement a basic bcmp") Cc: stable(a)vger.kernel.org Fixes: 8fc5b4d4121c ("purgatory: core purgatory functionality") Link: https://bugs.chromium.org/p/chromium/issues/detail?id=984056 Reported-by: Vaibhav Rustagi <vaibhavrustagi(a)google.com> Debugged-by: Vaibhav Rustagi <vaibhavrustagi(a)google.com> Debugged-by: Manoj Gupta <manojgupta(a)google.com> Suggested-by: Alistair Delva <adelva(a)google.com> Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com> Tested-by: Vaibhav Rustagi <vaibhavrustagi(a)google.com> --- Changes v4 -> v5: * None Changes v3 -> v4: * (style) open brace on newline * drop Vaibhav's SOB tag that was accidentally copy+pasta'd from v1. * Carry Vaibhav's tested by tag from v3 since v4 is strictly stylistic change from v3. * Drop cc'ing stable. Sasha's bot reports v1 doesn't cherry pick cleanly 5.1, so this series will require manual backports. Changes v2 -> v3: * Add bcmp implementation. * Drop tested-by tag (Vaibhav will help retest). * Cc stable Changes v1 -> v2: * Add Fixes tag. * Move this patch to first in the series. arch/x86/boot/string.c | 8 ++++++++ arch/x86/purgatory/Makefile | 3 +++ arch/x86/purgatory/purgatory.c | 6 ++++++ arch/x86/purgatory/string.c | 23 ----------------------- 4 files changed, 17 insertions(+), 23 deletions(-) delete mode 100644 arch/x86/purgatory/string.c diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c index 401e30ca0a75..8272a4492844 100644 --- a/arch/x86/boot/string.c +++ b/arch/x86/boot/string.c @@ -37,6 +37,14 @@ int memcmp(const void *s1, const void *s2, size_t len) return diff; } +/* + * Clang may lower `memcmp == 0` to `bcmp == 0`. + */ +int bcmp(const void *s1, const void *s2, size_t len) +{ + return memcmp(s1, s2, len); +} + int strcmp(const char *str1, const char *str2) { const unsigned char *s1 = (const unsigned char *)str1; diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile index 3cf302b26332..91ef244026d2 100644 --- a/arch/x86/purgatory/Makefile +++ b/arch/x86/purgatory/Makefile @@ -6,6 +6,9 @@ purgatory-y := purgatory.o stack.o setup-x86_$(BITS).o sha256.o entry64.o string targets += $(purgatory-y) PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y)) +$(obj)/string.o: $(srctree)/arch/x86/boot/compressed/string.c FORCE + $(call if_changed_rule,cc_o_c) + $(obj)/sha256.o: $(srctree)/lib/sha256.c FORCE $(call if_changed_rule,cc_o_c) diff --git a/arch/x86/purgatory/purgatory.c b/arch/x86/purgatory/purgatory.c index 6d8d5a34c377..b607bda786f6 100644 --- a/arch/x86/purgatory/purgatory.c +++ b/arch/x86/purgatory/purgatory.c @@ -68,3 +68,9 @@ void purgatory(void) } copy_backup_region(); } + +/* + * Defined in order to reuse memcpy() and memset() from + * arch/x86/boot/compressed/string.c + */ +void warn(const char *msg) {} diff --git a/arch/x86/purgatory/string.c b/arch/x86/purgatory/string.c deleted file mode 100644 index 01ad43873ad9..000000000000 --- a/arch/x86/purgatory/string.c +++ /dev/null @@ -1,23 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0-only -/* - * Simple string functions. - * - * Copyright (C) 2014 Red Hat Inc. - * - * Author: - * Vivek Goyal <vgoyal(a)redhat.com> - */ - -#include <linux/types.h> - -#include "../boot/string.c" - -void *memcpy(void *dst, const void *src, size_t len) -{ - return __builtin_memcpy(dst, src, len); -} - -void *memset(void *dst, int c, size_t len) -{ - return __builtin_memset(dst, c, len); -} -- 2.22.0.770.g0f2c4a37fd-goog

5 years, 4 months

1
1
0 0

NULL ptr deref in wq_worker_sleeping on 4.19

by Sasha Levin

Hi folks, We're seeing a rare panic on boot in wq_worker_sleeping() on boot in 4.19 kernels. I wasn't able to reproduce this with 5.2, but I'm not sure whether it's because the issue is fixed, or I was just unlucky. The panic looks like this: [ 0.852791] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 0.853260] PGD 0 P4D 0 [ 0.853260] Oops: 0000 [#1] SMP PTI [ 0.853260] CPU: 7 PID: 49 Comm: Not tainted 4.19.52-9858d02fd940 #1 [ 0.853260] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [ 0.853260] RIP: 0010:kthread_data+0x12/0x30 [ 0.853260] Code: 83 7f 58 00 74 02 0f 0b e9 bb 2d 19 00 0f 0b eb e2 0f 1f 80 00 00 00 00 0f 1f 44 00 00 f6 47 26 20 74 0c 48 8b 87 98 05 00 00 <48> 8b 40 10 c3 0f 0b 48 8b 87 98 05 00 00 48 8b 40 10 c3 90 66 2e [ 0.853260] RSP: 0000:ffffc900036abe38 EFLAGS: 00010002 [ 0.853260] RAX: 0000000000000000 RBX: ffff8887bfbe17c0 RCX: 0000000000000000 [ 0.853260] RDX: 0000000000000001 RSI: 000000000000000a RDI: ffff8887bbb4bb00 [ 0.853260] RBP: ffffc900036abea0 R08: 0000000000000000 R09: 0000000000000000 [ 0.853260] R10: ffffc9000368bd90 R11: 0000000000000000 R12: ffff8887bbb4bb00 [ 0.853260] R13: 0000000000000000 R14: ffffc900036abe60 R15: 0000000000000000 [ 0.853260] FS: 0000000000000000(0000) GS:ffff8887bfbc0000(0000) knlGS:0000000000000000 [ 0.853260] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.853260] CR2: 0000000000000068 CR3: 00000007df40a000 CR4: 00000000001406e0 [ 0.853260] Call Trace: [ 0.853260] wq_worker_sleeping+0xa/0x60 [ 0.853260] __schedule+0x571/0x8c0 [ 0.853260] schedule+0x32/0x80 [ 0.853260] worker_thread+0xc7/0x440 [ 0.853260] kthread+0xf8/0x130 [ 0.853260] ret_from_fork+0x35/0x40 [ 0.853260] Modules linked in: [ 0.853260] CR2: 0000000000000010 [ 0.853260] ---[ end trace 160fda44361ab977 ]--- I see that this area was recently touched by 6d25be5782e4 ("sched/core, workqueues: Distangle worker accounting from rq lock") but I'm not sure if it's related. -- Thanks, Sasha

5 years, 4 months

4
5
0 0

[PATCH] drm/msm/dsi: Fix return value check for clk_get_parent

by Sean Paul

From: Sean Paul <seanpaul(a)chromium.org> clk_get_parent returns an error pointer upon failure, not NULL. So the checks as they exist won't catch a failure. This patch changes the checks and the return values to properly handle an error pointer. Fixes: c4d8cfe516dc ("drm/msm/dsi: add implementation for helper functions") Cc: Sibi Sankar <sibis(a)codeaurora.org> Cc: Sean Paul <seanpaul(a)chromium.org> Cc: Rob Clark <robdclark(a)chromium.org> Cc: <stable(a)vger.kernel.org> # v4.19+ Signed-off-by: Sean Paul <seanpaul(a)chromium.org> --- drivers/gpu/drm/msm/dsi/dsi_host.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index aa35d18ab43c9..02acb4338721a 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -421,15 +421,15 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host) } msm_host->byte_clk_src = clk_get_parent(msm_host->byte_clk); - if (!msm_host->byte_clk_src) { - ret = -ENODEV; + if (IS_ERR(msm_host->byte_clk_src)) { + ret = PTR_ERR(msm_host->byte_clk_src); pr_err("%s: can't find byte_clk clock. ret=%d\n", __func__, ret); goto exit; } msm_host->pixel_clk_src = clk_get_parent(msm_host->pixel_clk); - if (!msm_host->pixel_clk_src) { - ret = -ENODEV; + if (IS_ERR(msm_host->pixel_clk_src)) { + ret = PTR_ERR(msm_host->pixel_clk_src); pr_err("%s: can't find pixel_clk clock. ret=%d\n", __func__, ret); goto exit; } -- Sean Paul, Software Engineer, Google / Chromium OS

5 years, 4 months

1
0
0 0

Fwd: ❌ FAIL: Stable queue: queue-5.2

by Major Hayden

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hey there, We are still working through some improvements on our platform and we haven't re-enabled automated emails to the list yet. However, we did just stumble into this compile error for aarch64 with the latest patches in stable-queue: > 00:03:02 CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/table.o > 00:03:02 drivers/spi/spi-bcm2835.c: In function ‘bcm2835_spi_transfer_one’: > 00:03:02 drivers/spi/spi-bcm2835.c:768:21: error: ‘ctlr’ undeclared (first use in this function) > 00:03:02 768 | tfr->rx_buf != ctlr->dummy_rx) > 00:03:02 | ^~~~ > 00:03:02 drivers/spi/spi-bcm2835.c:768:21: note: each undeclared identifier is reported only once for each function it appears in > 00:03:02 CC [M] drivers/net/ethernet/mellanox/mlxsw/spectrum2_acl_tcam.o > 00:03:02 make[4]: *** [scripts/Makefile.build:284: drivers/spi/spi-bcm2835.o] Error 1 Please let me know if anyone has more questions! The full build log is attached to this email. - -- Major Hayden - -------- Forwarded Message -------- Subject: ❌ FAIL: Stable queue: queue-5.2 Date: Wed, 7 Aug 2019 12:23:59 -0400 From: CKI Project <cki-project(a)redhat.com> To: CKI Project <cki-project(a)redhat.com> Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 5697a9d3d55f - Linux 5.2.7 The results of these automated tests are provided below. Overall result: FAILED (see details below) Merge: OK Compile: FAILED We attempted to compile the kernel for multiple architectures, but the compile failed on one or more architectures: aarch64: FAILED (see build-aarch64.log.xz attachment) We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Merge testing - ------------- We cloned this repository and checked out the following commit: Repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 5697a9d3d55f - Linux 5.2.7 We grabbed the 229ceaed3194 commit of the stable queue repository. We then merged the patchset with `git am`: scsi-fcoe-embed-fc_rport_priv-in-fcoe_rport-structure.patch libnvdimm-bus-prepare-the-nd_ioctl-path-to-be-re-ent.patch libnvdimm-bus-fix-wait_nvdimm_bus_probe_idle-abba-de.patch alsa-usb-audio-sanity-checks-for-each-pipe-and-ep-ty.patch alsa-usb-audio-fix-gpf-in-snd_usb_pipe_sanity_check.patch hid-wacom-fix-bit-shift-for-cintiq-companion-2.patch hid-add-quirk-for-hp-x1200-pixart-oem-mouse.patch spi-bcm2835-fix-3-wire-mode-if-dma-is-enabled.patch Compile testing - --------------- We compiled the kernel for 4 architectures: aarch64: build options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: build options: -j30 INSTALL_MOD_STRIP=1 targz-pkg s390x: build options: -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: build options: -j30 INSTALL_MOD_STRIP=1 targz-pkg -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG/mSZJWWADNpjCUrc3BR4MEBH7EFAl1K/CsACgkQc3BR4MEB H7FcyRAAnLTIguHxsPfqPDz6Gv/LkY4fbWvJUGv2Q20E2WvXhmebhs7VF14i1Oww kFYzTzZKsDmvWcXPp/ZBi3TS5yuumcorEQ2BCZvRs4q09twixvUhLQxt5TDY98h2 yNKhSi64XttfT75yOumWfric/NjJCLOhICcy01UKI4KhWZGb9FJJYoM6s/uIhsHJ LdovohS60e/wV8S1w+B4RvXfC1Cn99gvQhemLDKN4uCyYtkOwfqXVru6PRitCEZv VbvbciodOmJ+3BY14628tXarzguCN8ShP+vuOVoTWC7x4sEEU6e29EO0HhNmif/8 7qfG0DXTS4+XGD6hvZXpBEpXoG/sGFPS95SlyZxkb6zQq4WJn5KU4bALgTFrLj8O emRM7dNza+Emgu3RK9rP6uShJwHcwfpNXukpX6OyNBkmUQVmD5syuEFFQEzNzkmG i7z1EnjdZvMUJpX7f3ZqDWu8ntTVckPDW684DtPtl613Qf4Rj7OgXChXU01On99e zuQGPZSO6NsoAanDsi+0IzvyyP/R8vBgOFaBoQBoKtVExlUDWSaViq83KQ7KtDy4 6JQFMsDaqi6U+Ii2/EBjp+Tup5r6Y8DTvbPAhwMCPUhf0h5ugRzmrgQuykY0ZCf6 4Erp38IvPH0zwgQRQDvEcRCVgbVyG02BTUtQcG3EPqbCpzJUeRA= =YRI7 -----END PGP SIGNATURE-----

5 years, 4 months

2
1
0 0

FAILED: patch "[PATCH] spi: bcm2835: Fix 3-wire mode if DMA is enabled" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 8d8bef50365847134b51c1ec46786bc2873e4e47 Mon Sep 17 00:00:00 2001 From: Lukas Wunner <lukas(a)wunner.de> Date: Wed, 3 Jul 2019 12:29:31 +0200 Subject: [PATCH] spi: bcm2835: Fix 3-wire mode if DMA is enabled MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Commit 6935224da248 ("spi: bcm2835: enable support of 3-wire mode") added 3-wire support to the BCM2835 SPI driver by setting the REN bit (Read Enable) in the CS register when receiving data. The REN bit puts the transmitter in high-impedance state. The driver recognizes that data is to be received by checking whether the rx_buf of a transfer is non-NULL. Commit 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions") subsequently broke 3-wire support because it set the SPI_MASTER_MUST_RX flag which causes spi_map_msg() to replace rx_buf with a dummy buffer if it is NULL. As a result, rx_buf is *always* non-NULL if DMA is enabled. Reinstate 3-wire support by not only checking whether rx_buf is non-NULL, but also checking that it is not the dummy buffer. Fixes: 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions") Reported-by: Nuno Sá <nuno.sa(a)analog.com> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Cc: stable(a)vger.kernel.org # v4.2+ Cc: Martin Sperl <kernel(a)martin.sperl.org> Acked-by: Stefan Wahren <wahrenst(a)gmx.net> Link: https://lore.kernel.org/r/328318841455e505370ef8ecad97b646c033dc8a.15621485… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c index 6f243a90c844..840b1b8ff3dc 100644 --- a/drivers/spi/spi-bcm2835.c +++ b/drivers/spi/spi-bcm2835.c @@ -834,7 +834,8 @@ static int bcm2835_spi_transfer_one(struct spi_controller *ctlr, bcm2835_wr(bs, BCM2835_SPI_CLK, cdiv); /* handle all the 3-wire mode */ - if ((spi->mode & SPI_3WIRE) && (tfr->rx_buf)) + if (spi->mode & SPI_3WIRE && tfr->rx_buf && + tfr->rx_buf != ctlr->dummy_rx) cs |= BCM2835_SPI_CS_REN; else cs &= ~BCM2835_SPI_CS_REN;

5 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] spi: bcm2835: Fix 3-wire mode if DMA is enabled" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 8d8bef50365847134b51c1ec46786bc2873e4e47 Mon Sep 17 00:00:00 2001 From: Lukas Wunner <lukas(a)wunner.de> Date: Wed, 3 Jul 2019 12:29:31 +0200 Subject: [PATCH] spi: bcm2835: Fix 3-wire mode if DMA is enabled MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Commit 6935224da248 ("spi: bcm2835: enable support of 3-wire mode") added 3-wire support to the BCM2835 SPI driver by setting the REN bit (Read Enable) in the CS register when receiving data. The REN bit puts the transmitter in high-impedance state. The driver recognizes that data is to be received by checking whether the rx_buf of a transfer is non-NULL. Commit 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions") subsequently broke 3-wire support because it set the SPI_MASTER_MUST_RX flag which causes spi_map_msg() to replace rx_buf with a dummy buffer if it is NULL. As a result, rx_buf is *always* non-NULL if DMA is enabled. Reinstate 3-wire support by not only checking whether rx_buf is non-NULL, but also checking that it is not the dummy buffer. Fixes: 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions") Reported-by: Nuno Sá <nuno.sa(a)analog.com> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Cc: stable(a)vger.kernel.org # v4.2+ Cc: Martin Sperl <kernel(a)martin.sperl.org> Acked-by: Stefan Wahren <wahrenst(a)gmx.net> Link: https://lore.kernel.org/r/328318841455e505370ef8ecad97b646c033dc8a.15621485… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c index 6f243a90c844..840b1b8ff3dc 100644 --- a/drivers/spi/spi-bcm2835.c +++ b/drivers/spi/spi-bcm2835.c @@ -834,7 +834,8 @@ static int bcm2835_spi_transfer_one(struct spi_controller *ctlr, bcm2835_wr(bs, BCM2835_SPI_CLK, cdiv); /* handle all the 3-wire mode */ - if ((spi->mode & SPI_3WIRE) && (tfr->rx_buf)) + if (spi->mode & SPI_3WIRE && tfr->rx_buf && + tfr->rx_buf != ctlr->dummy_rx) cs |= BCM2835_SPI_CS_REN; else cs &= ~BCM2835_SPI_CS_REN;

5 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] spi: bcm2835: Fix 3-wire mode if DMA is enabled" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 8d8bef50365847134b51c1ec46786bc2873e4e47 Mon Sep 17 00:00:00 2001 From: Lukas Wunner <lukas(a)wunner.de> Date: Wed, 3 Jul 2019 12:29:31 +0200 Subject: [PATCH] spi: bcm2835: Fix 3-wire mode if DMA is enabled MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Commit 6935224da248 ("spi: bcm2835: enable support of 3-wire mode") added 3-wire support to the BCM2835 SPI driver by setting the REN bit (Read Enable) in the CS register when receiving data. The REN bit puts the transmitter in high-impedance state. The driver recognizes that data is to be received by checking whether the rx_buf of a transfer is non-NULL. Commit 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions") subsequently broke 3-wire support because it set the SPI_MASTER_MUST_RX flag which causes spi_map_msg() to replace rx_buf with a dummy buffer if it is NULL. As a result, rx_buf is *always* non-NULL if DMA is enabled. Reinstate 3-wire support by not only checking whether rx_buf is non-NULL, but also checking that it is not the dummy buffer. Fixes: 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions") Reported-by: Nuno Sá <nuno.sa(a)analog.com> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Cc: stable(a)vger.kernel.org # v4.2+ Cc: Martin Sperl <kernel(a)martin.sperl.org> Acked-by: Stefan Wahren <wahrenst(a)gmx.net> Link: https://lore.kernel.org/r/328318841455e505370ef8ecad97b646c033dc8a.15621485… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c index 6f243a90c844..840b1b8ff3dc 100644 --- a/drivers/spi/spi-bcm2835.c +++ b/drivers/spi/spi-bcm2835.c @@ -834,7 +834,8 @@ static int bcm2835_spi_transfer_one(struct spi_controller *ctlr, bcm2835_wr(bs, BCM2835_SPI_CLK, cdiv); /* handle all the 3-wire mode */ - if ((spi->mode & SPI_3WIRE) && (tfr->rx_buf)) + if (spi->mode & SPI_3WIRE && tfr->rx_buf && + tfr->rx_buf != ctlr->dummy_rx) cs |= BCM2835_SPI_CS_REN; else cs &= ~BCM2835_SPI_CS_REN;

5 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2019