- 25 Jun, 2019 40 commits
-
-
Yonglong Liu authored
[ Upstream commit 2e1f1648 ] When doing a loopback test at copper ports, the serdes loopback and the phy loopback will fail, because of the adjust link had not finished, and phy not ready. Adds sleep between adjust link and test process to fix it. Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Nikita Yushchenko authored
[ Upstream commit 62394708 ] When non-bridged, non-vlan'ed mv88e6xxx port is moving down, error message is logged: failed to kill vid 0081/0 for device eth_cu_1000_4 This is caused by call from __vlan_vid_del() with vin set to zero, over call chain this results into _mv88e6xxx_port_vlan_del() called with vid=0, and mv88e6xxx_vtu_get() called from there returns -EINVAL. On symmetric path moving port up, call goes through mv88e6xxx_port_vlan_prepare() that calls mv88e6xxx_port_check_hw_vlan() that returns -EOPNOTSUPP for zero vid. This patch changes mv88e6xxx_vtu_get() to also return -EOPNOTSUPP for zero vid, then this error code is explicitly cleared in dsa_slave_vlan_rx_kill_vid() and error message is no longer logged. Signed-off-by:
Nikita Yushchenko <nikita.yoush@cogentembedded.com> Reviewed-by:
Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by:
-
Naresh Kamboju authored
[ Upstream commit bc2cce3f ] Add test_vmalloc.sh to TEST_FILES to make sure it gets installed for run_vmtests. Fixed below error: ./run_vmtests: line 217: ./test_vmalloc.sh: No such file or directory Tested with: make TARGETS=vm install INSTALL_PATH=$PWD/x Signed-off-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Alakesh Haloi authored
[ Upstream commit 98a13a8d ] Fixes following compiler warning userfaultfd.c: In function ‘usage’: userfaultfd.c:126:2: warning: format not a string literal and no format arguments [-Wformat-security] fprintf(stderr, examples); Signed-off-by:
Alakesh Haloi <alakesh.haloi@gmail.com> Reviewed-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
-
Alex Shi authored
[ Upstream commit f97f3f88 ] The test_core will skip the test_cgcore_no_internal_process_constraint_on_threads test case if the 'cpu' controller missing in root's subtree_control. In fact we need to set the 'cpu' in subtree_control, to make the testing meaningful. ./test_core ... ok 4 # skip test_cgcore_no_internal_process_constraint_on_threads ... Signed-off-by:
Alex Shi <alex.shi@linux.alibaba.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Roman Gushchin <guro@fb.com> Cc: Claudio Zumbo <claudioz@fb.com> Cc: Claudio <claudiozumbo@gmail.com> Cc: linux-kselftest@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by:
Roman Gushchin <guro@fb.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Alex Shi authored
[ Upstream commit 00e38a5d ] The cgroup testing relys on the root cgroup's subtree_control setting, If the 'memory' controller isn't set, some test cases will be failed as following: $sudo ./test_core not ok 1 test_cgcore_internal_process_constraint ok 2 test_cgcore_top_down_constraint_enable not ok 3 test_cgcore_top_down_constraint_disable ... To correct this unexpected failure, this patch write the 'memory' to subtree_control of root to get a right result. Signed-off-by:
-
Alex Shi authored
[ Upstream commit f6131f28 ] The cgroup testing relies on the root cgroup's subtree_control setting, If the 'memory' controller isn't set, all test cases will be failed as following: $ sudo ./test_memcontrol not ok 1 test_memcg_subtree_control not ok 2 test_memcg_current ok 3 # skip test_memcg_min not ok 4 test_memcg_low not ok 5 test_memcg_high not ok 6 test_memcg_max not ok 7 test_memcg_oom_events ok 8 # skip test_memcg_swap_max not ok 9 test_memcg_sock not ok 10 test_memcg_oom_group_leaf_events not ok 11 test_memcg_oom_group_parent_events not ok 12 test_memcg_oom_group_score_events To correct this unexpected failure, this patch write the 'memory' to subtree_control of root to get a right result. Signed-off-by:
-
Guenter Roeck authored
[ Upstream commit adefd051 ] Since commit 9012d011 ("compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING"), xtensa:tinyconfig fails to build with section mismatch errors. WARNING: vmlinux.o(.text.unlikely+0x68): Section mismatch in reference from the function ___pa() to the function .meminit.text:memblock_reserve() WARNING: vmlinux.o(.text.unlikely+0x74): Section mismatch in reference from the function mem_reserve() to the function .meminit.text:memblock_reserve() FATAL: modpost: Section mismatches detected. This was not seen prior to the above mentioned commit because mem_reserve() was always inlined. Mark mem_reserve(() as __init_memblock to have it reside in the same section as memblock_reserve(). Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Message-Id: <1559220098-9955-1-git-send-email-linux@roeck-us.net> Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Eric Biggers authored
[ Upstream commit 7829a0c1 ] When I added the sanity check of 'descsize', I missed that the child hash tfm needs to be freed if the sanity check fails. Of course this should never happen, hence the use of WARN_ON(), but it should be fixed. Fixes: e1354400 ("crypto: hash - fix incorrect HASH_MAX_DESCSIZE") Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
YueHaibing authored
[ Upstream commit f532beee ] Fixes gcc '-Wunused-but-set-variable' warning: arch/mips/kernel/uprobes.c: In function 'arch_uprobe_pre_xol': arch/mips/kernel/uprobes.c:115:17: warning: variable 'epc' set but not used [-Wunused-but-set-variable] It's never used since introduction in commit 40e084a5 ("MIPS: Add uprobes support.") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Paul Burton <paul.burton@mips.com> Cc: <ralf@linux-mips.org> Cc: <jhogan@kernel.org> Cc: <linux-kernel@vger.kernel.org> Cc: <linux-mips@vger.kernel.org> Signed-off-by:
-
Kamenee Arumugam authored
[ Upstream commit 97736f36 ] User applications can register memory regions for TID buffers that are not aligned on page boundaries. Hfi1 is expected to pin those pages in memory and cache the pages with mmu_rb. The rb tree will fail to insert pages that are not aligned correctly. Validate whether a given virtual address is page aligned before pinning. Fixes: 7e7a436e ("staging/hfi1: Add TID entry program function body") Reviewed-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by:
Kamenee Arumugam <kamenee.arumugam@intel.com> Signed-off-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Mike Marciniszyn authored
[ Upstream commit 35164f52 ] The command 'ibv_devinfo -v' reports 0 for max_mr. Fix by assigning the query values after the mr lkey_table has been built rather than early on in the driver. Fixes: 7b1e2099 ("IB/rdmavt: Move memory registration into rdmavt") Reviewed-by:
Josh Collier <josh.d.collier@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
-
Mike Marciniszyn authored
[ Upstream commit 6d517353 ] By code inspection, the freeze_work is never canceled. Fix by adding a cancel_work_sync in the shutdown path to insure it is no longer running. Fixes: 77241056 ("IB/hfi1: add driver files") Reviewed-by:
-
Mike Marciniszyn authored
[ Upstream commit 2abae62a ] The qpn allocation logic has a WARN_ON() that intends to detect the use of an index that will introduce bits in the lower order bits of the QOS bits in the QPN. Unfortunately, it has the following bugs: - it misfires when wrapping QPN allocation for non-QOS - it doesn't correctly detect low order QOS bits (despite the comment) The WARN_ON() should not be applied to non-QOS (qos_shift == 1). Additionally, it SHOULD test the qpn bits per the table below: 2 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^ [ 0, 0, 0, 0, 0, 0, sc0], qp bit 1 always 0* 3-4 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^ [ 0, 0, 0, 0, 0, sc1, sc0], qp bits [21] always 0 5-8 data VLs: [qp7, qp6, qp5, qp4, qp3, qp2, qp1] ^ [ 0, 0, 0, 0, sc2, sc1, sc0] qp bits [321] always 0 Fix by qualifying the warning for qos_shift > 1 and producing the correct mask to insure the above bits are zero without generating a superfluous warning. Fixes: 501edc42 ("IB/rdmavt: Correct warning during QPN allocation") Reviewed-by:
Kaike Wan <kaike.wan@intel.com> Signed-off-by:
-
Oded Gabbay authored
[ Upstream commit d7241701 ] This patch fix a bug in the mmu code that checks whether we can use huge page mappings for host pages. The code is supposed to enable huge page mappings only if ALL DMA addresses are aligned to 2MB AND the number of pages in each DMA chunk is a modulo of the number of pages in 2MB. However, the code ignored the first requirement for the first DMA chunk. This patch fix that issue by making sure the requirement of address alignment is validated against all DMA chunks. Signed-off-by:
Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by:
-
Helge Deller authored
[ Upstream commit 6b98d913 ] Avoid such compiler warnings: arch/parisc/math-emu/cnv_float.h:71:27: warning: ‘<<’ in boolean context, did you mean ‘<’ ? [-Wint-in-bool-context] ((Dintp1(dint_valueA) << 33 - SGL_EXP_LENGTH) || Dintp2(dint_valueB)) arch/parisc/math-emu/fcnvxf.c:257:6: note: in expansion of macro ‘Dint_isinexact_to_sgl’ if (Dint_isinexact_to_sgl(srcp1,srcp2)) { Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 1c7ebeab ] BUG: memory leak unreferenced object 0xffff8881df48cda0 (size 16): comm "syz-executor.0", pid 5077, jiffies 4295994670 (age 22.280s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d2d0d5fe>] parport_register_dev_model+0x141/0x6e0 [parport] [<00000000782f6dab>] 0xffffffffc15d1196 [<00000000d2ca6ae4>] platform_drv_probe+0x7e/0x100 [<00000000628c2a94>] really_probe+0x342/0x4d0 [<000000006874f5da>] driver_probe_device+0x8c/0x170 [<00000000424de37a>] __device_attach_driver+0xda/0x100 [<000000002acab09a>] bus_for_each_drv+0xfe/0x170 [<000000003d9e5f31>] __device_attach+0x190/0x230 [<0000000035d32f80>] bus_probe_device+0x123/0x140 [<00000000a05ba627>] device_add+0x7cc/0xce0 [<000000003f7560bf>] platform_device_add+0x230/0x3c0 [<000000002a0be07d>] 0xffffffffc15d0949 [<000000007361d8d2>] port_check+0x3b/0x50 [parport] [<000000004d67200f>] bus_for_each_dev+0x115/0x180 [<000000003ccfd11c>] __parport_register_driver+0x1f0/0x210 [parport] [<00000000987f06fc>] 0xffffffffc15d803e After commit 4e5a74f1 ("parport: Revert "parport: fix memory leak""), free_pardevice do not free par_dev->state, we should free it in error path of parport_register_dev_model before return. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 4e5a74f1 ("parport: Revert "parport: fix memory leak"") Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Scott Wood authored
[ Upstream commit dfe3de8d ] struct dfl_feature_platform_data (and it's mutex) is used by both fme and port devices, and when lockdep is enabled it complains about nesting between these locks. Tell lockdep about the difference so it can track each class separately. Here's the lockdep complaint: [ 409.680668] WARNING: possible recursive locking detected [ 409.685983] 5.1.0-rc3.fpga+ #1 Tainted: G E [ 409.691469] -------------------------------------------- [ 409.696779] fpgaconf/9348 is trying to acquire lock: [ 409.701746] 00000000a443fe2e (&pdata->lock){+.+.}, at: port_enable_set+0x24/0x60 [dfl_afu] [ 409.710006] [ 409.710006] but task is already holding lock: [ 409.715837] 0000000063b78782 (&pdata->lock){+.+.}, at: fme_pr_ioctl+0x21d/0x330 [dfl_fme] [ 409.724012] [ 409.724012] other info that might help us debug this: [ 409.730535] Possible unsafe locking scenario: [ 409.730535] [ 409.736457] CPU0 [ 409.738910] ---- [ 409.741360] lock(&pdata->lock); [ 409.744679] lock(&pdata->lock); [ 409.747999] [ 409.747999] *** DEADLOCK *** [ 409.747999] [ 409.753920] May be due to missing lock nesting notation [ 409.753920] [ 409.760704] 4 locks held by fpgaconf/9348: [ 409.764805] #0: 0000000063b78782 (&pdata->lock){+.+.}, at: fme_pr_ioctl+0x21d/0x330 [dfl_fme] [ 409.773408] #1: 00000000213c8a66 (®ion->mutex){+.+.}, at: fpga_region_program_fpga+0x24/0x200 [fpga_region] [ 409.783489] #2: 00000000fe63afb9 (&mgr->ref_mutex){+.+.}, at: fpga_mgr_lock+0x15/0x40 [fpga_mgr] [ 409.792354] #3: 000000000b2285c5 (&bridge->mutex){+.+.}, at: __fpga_bridge_get+0x26/0xa0 [fpga_bridge] [ 409.801740] [ 409.801740] stack backtrace: [ 409.806102] CPU: 45 PID: 9348 Comm: fpgaconf Kdump: loaded Tainted: G E 5.1.0-rc3.fpga+ #1 [ 409.815658] Hardware name: Intel Corporation S2600BT/S2600BT, BIOS SE5C620.86B.01.00.0763.022420181017 02/24/2018 [ 409.825911] Call Trace: [ 409.828369] dump_stack+0x5e/0x8b [ 409.831686] __lock_acquire+0xf3d/0x10e0 [ 409.835612] ? find_held_lock+0x3c/0xa0 [ 409.839451] lock_acquire+0xbc/0x1d0 [ 409.843030] ? port_enable_set+0x24/0x60 [dfl_afu] [ 409.847823] ? port_enable_set+0x24/0x60 [dfl_afu] [ 409.852616] __mutex_lock+0x86/0x970 [ 409.856195] ? port_enable_set+0x24/0x60 [dfl_afu] [ 409.860989] ? port_enable_set+0x24/0x60 [dfl_afu] [ 409.865777] ? __mutex_unlock_slowpath+0x4b/0x290 [ 409.870486] port_enable_set+0x24/0x60 [dfl_afu] [ 409.875106] fpga_bridges_disable+0x36/0x50 [fpga_bridge] [ 409.880502] fpga_region_program_fpga+0xea/0x200 [fpga_region] [ 409.886338] fme_pr_ioctl+0x13e/0x330 [dfl_fme] [ 409.890870] fme_ioctl+0x66/0xe0 [dfl_fme] [ 409.894973] do_vfs_ioctl+0xa9/0x720 [ 409.898548] ? lockdep_hardirqs_on+0xf0/0x1a0 [ 409.902907] ksys_ioctl+0x60/0x90 [ 409.906225] __x64_sys_ioctl+0x16/0x20 [ 409.909981] do_syscall_64+0x5a/0x220 [ 409.913644] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 409.918698] RIP: 0033:0x7f9d31b9b8d7 [ 409.922276] Code: 44 00 00 48 8b 05 b9 15 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 89 15 2d 00 f7 d8 64 89 01 48 [ 409.941020] RSP: 002b:00007ffe4cae0d68 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 [ 409.948588] RAX: ffffffffffffffda RBX: 00007f9d32ade6a0 RCX: 00007f9d31b9b8d7 [ 409.955719] RDX: 00007ffe4cae0df0 RSI: 000000000000b680 RDI: 0000000000000003 [ 409.962852] RBP: 0000000000000003 R08: 00007f9d2b70a177 R09: 00007ffe4cae0e40 [ 409.969984] R10: 00007ffe4cae0160 R11: 0000000000000202 R12: 00007ffe4cae0df0 [ 409.977115] R13: 000000000000b680 R14: 0000000000000000 R15: 00007ffe4cae0f60 Signed-off-by:
Scott Wood <swood@redhat.com> Acked-by:
Wu Hao <hao.wu@intel.com> Acked-by:
Alan Tull <atull@kernel.org> Signed-off-by:
-
Scott Wood authored
[ Upstream commit 13069847 ] dma_mapping_error() was being called on a different device struct than what was passed to map/unmap. Besides rendering the error checking ineffective, it caused a debug splat with CONFIG_DMA_API_DEBUG. Signed-off-by:
Moritz Fischer <mdf@kernel.org> Acked-by:
-
Wen Yang authored
[ Upstream commit f5dd8732 ] The refcount of fw_np has already been decreased by of_find_matching_node() so it shouldn't be used anymore. This patch adds an of_node_get() before of_find_matching_node() to avoid the use-after-free problem. Fixes: e7eef1d7 ("fpga: add intel stratix10 soc fpga manager driver") Signed-off-by:
Wen Yang <wen.yang99@zte.com.cn> Cc: Alan Tull <atull@kernel.org> Cc: Moritz Fischer <mdf@kernel.org> Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Cc: linux-fpga@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Acked-by:
-
Masahiro Yamada authored
[ Upstream commit 6074c33c ] To meet the 'i' (immediate) constraint for the asm operands, this function must be always inlined. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Jose Abreu authored
[ Upstream commit 4c70850a ] Add the binding for RX/TX fifo size of GMAC node. Cc: Joao Pinto <jpinto@synopsys.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Vineet Gupta <vgupta@synopsys.com> Tested-by:
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Acked-by:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Jose Abreu authored
[ Upstream commit ecc906a1 ] GMAC controller on HSDK boards supports 256 Hash Table size so we need to add the multicast filter bins property. This allows for the Hash filter to work properly using stmmac driver. Cc: Joao Pinto <jpinto@synopsys.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Acked-by:
-
Eric Long authored
[ Upstream commit c434e377 ] Move the 2-stage configuration before configuring the link-list mode, since we will use some 2-stage configuration to fill the link-list configuration. Signed-off-by:
Eric Long <eric.long@unisoc.com> Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Eric Long authored
[ Upstream commit 89d03b3c ] The maximum value of block length is 0xffff, so if the configured transfer length is more than 0xffff, that will cause block length overflow to lead a configuration error. Thus we can set block length as the maximum burst length to avoid this issue, since the maximum burst length will not be a big value which is more than 0xffff. Signed-off-by:
-
Eric Long authored
[ Upstream commit 3d626a97 ] The 2-stage destination channel will be triggered by source channel automatically, which means we should not trigger it by software request. Signed-off-by:
-
Baolin Wang authored
[ Upstream commit 58152b0e ] When user terminates one DMA channel to free all its descriptors, but at the same time one transaction interrupt was triggered possibly, now we should not handle this interrupt by validating if the 'schan->cur_desc' was set as NULL to avoid crashing the kernel. Signed-off-by:
-
Baolin Wang authored
[ Upstream commit 16d0f85e ] We will get a NULL virtual descriptor by vchan_find_desc() when the descriptor has been submitted, that will crash the kernel when getting the descriptor status. In this case, since the descriptor has been submitted to process, but it is not completed now, which means the descriptor is listed into the 'vc->desc_submitted' list now. So we can not get current processing descriptor by vchan_find_desc(), but the pointer 'schan->cur_desc' will point to the current processing descriptor, then we can use 'schan->cur_desc' to get current processing descriptor's status to avoid this issue. Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 069b3c42 ] The mtk_cqdma_poll_engine_done() function takes a true/false parameter where true means it's called from atomic context. There are a couple places where it was set to false but it's actually in atomic context so it should be true. All the callers for mtk_cqdma_hard_reset() are holding a spin_lock and in mtk_cqdma_free_chan_resources() we take a spin_lock before calling the mtk_cqdma_poll_engine_done() function. Fixes: b1f01e48 ("dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 0788611c ] In the unlikely event that axi_desc_get returns a null desc in the very first iteration of the while-loop the error exit path ends up calling axi_desc_put on a null pointer 'first' and this causes a null pointer dereference. Fix this by adding a null check on pointer 'first' before calling axi_desc_put. Addresses-Coverity: ("Explicit null dereference") Fixes: 1fe20f1b ("dmaengine: Introduce DW AXI DMAC driver") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Paul Cercueil authored
[ Upstream commit 4e4106f5 ] When a multi-descriptor DMA transfer is in progress, the "IRQ pending" flag will apparently be set for that channel as soon as the last descriptor loads, way before the IRQ actually happens. This behaviour has been observed on the JZ4725B, but maybe other SoCs are affected. In the case where another DMA transfer is running into completion on a separate channel, the IRQ handler would then run the completion handler for our previous channel even if the transfer didn't actually finish. Fix this by checking in the completion handler that we're indeed done; if not the interrupted DMA transfer will simply be resumed. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Vineet Gupta authored
[ Upstream commit 89c92142 ] | arch/arc/mm/tlb.c:914:2: warning: variable length array 'pd0' is used [-Wvla] | arch/arc/include/asm/cmpxchg.h:95:29: warning: value computed is not used [-Wunused-value] Signed-off-by:
-
Kees Cook authored
[ Upstream commit 2bf8496f ] The prior implementation of the KERNEL_DS fault checking would work on any unmapped kernel address, but this was narrowed to the non-canonical range instead. This adjusts the LKDTM test to match. Fixes: 00c42373 ("x86-64: add warning for non-canonical user access address dereferences") Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Douglas Anderson authored
commit 65dade60 upstream. When Broadcom SDIO cards are idled they go to sleep and a whole separate subsystem takes over their SDIO communication. This is the Always-On-Subsystem (AOS) and it can't handle tuning requests. Specifically, as tested on rk3288-veyron-minnie (which reports having BCM4354/1 in dmesg), if I force a retune in brcmf_sdio_kso_control() when "on = 1" (aka we're transition from sleep to wake) by whacking: bus->sdiodev->func1->card->host->need_retune = 1 ...then I can often see tuning fail. In this case dw_mmc reports "All phases bad!"). Note that I don't get 100% failure, presumably because sometimes the card itself has already transitioned away from the AOS itself by the time we try to wake it up. If I force retuning when "on = 0" (AKA force retuning right before sending the command to go to sleep) then retuning is always OK. NOTE: we need _both_ this patch and the patch to avoid triggering tuning due to CRC errors in the sleep/wake transition, AKA ("brcmfmac: sdio: Disable auto-tuning around commands expected to fail"). Though both patches handle issues with Broadcom's AOS, the problems are distinct: 1. We want to defer (but not ignore) asynchronous (like timer-requested) tuning requests till the card is awake. However, we want to ignore CRC errors during the transition, we don't want to queue deferred tuning request. 2. You could imagine that the AOS could implement retuning but we could still get errors while transitioning in and out of the AOS. Similarly you could imagine a seamless transition into and out of the AOS (with no CRC errors) even if the AOS couldn't handle tuning. ALSO NOTE: presumably there is never a desperate need to retune in order to wake up the card, since doing so is impossible. Luckily the only way the card can get into sleep state is if we had a good enough tuning to send it the command to put it into sleep, so presumably that "good enough" tuning is enough to wake us up, at least with a few retries. Cc: stable@vger.kernel.org #v4.18+ Signed-off-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Reviewed-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Acked-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Douglas Anderson authored
commit 2de0b42d upstream. There are certain cases, notably when transitioning between sleep and active state, when Broadcom SDIO WiFi cards will produce errors on the SDIO bus. This is evident from the source code where you can see that we try commands in a loop until we either get success or we've tried too many times. The comment in the code reinforces this by saying "just one write attempt may fail" Unfortunately these failures sometimes end up causing an "-EILSEQ" back to the core which triggers a retuning of the SDIO card and that blocks all traffic to the card until it's done. Let's disable retuning around the commands we expect might fail. Cc: stable@vger.kernel.org #v4.18+ Signed-off-by:
-
Douglas Anderson authored
commit abdd5dcc upstream. This reverts commit 29f65891. After that patch landed I find that my kernel log on rk3288-veyron-minnie and rk3288-veyron-speedy is filled with: brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110 This seems to happen every time the Broadcom WiFi transitions out of sleep mode. Reverting the commit fixes the problem for me, so that's what this patch does. Note that, in general, the justification in the original commit seemed a little weak. It looked like someone was testing on a SD card controller that would sometimes die if there were CRC errors on the bus. This used to happen back in early days of dw_mmc (the controller on my boards), but we fixed it. Disabling a feature on all boards just because one SD card controller is broken seems bad. Fixes: 29f65891 ("brcmfmac: disable command decode in sdio_aos") Cc: Wright Feng <wright.feng@cypress.com> Cc: Double Lo <double.lo@cypress.com> Cc: Madhan Mohan R <madhanmohan.r@cypress.com> Cc: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by:
-
Mike Salvatore authored
commit 156e4299 upstream. Each function that manipulates the aa_ext struct should reset it's "pos" member on failure. This ensures that, on failure, no changes are made to the state of the aa_ext struct. There are paths were elements are optional and the error path is used to indicate the optional element is not present. This means instead of just aborting on error the unpack stream can become unsynchronized on optional elements, if using one of the affected functions. Cc: stable@vger.kernel.org Fixes: 736ec752 ("AppArmor: policy routines for loading and unpacking policy") Signed-off-by:
Mike Salvatore <mike.salvatore@canonical.com> Signed-off-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
-
Jann Horn authored
commit 8404d7a6 upstream. A packed AppArmor policy contains null-terminated tag strings that are read by unpack_nameX(). However, unpack_nameX() uses string functions on them without ensuring that they are actually null-terminated, potentially leading to out-of-bounds accesses. Make sure that the tag string is null-terminated before passing it to strcmp(). Cc: stable@vger.kernel.org Fixes: 736ec752 ("AppArmor: policy routines for loading and unpacking policy") Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
-
John Johansen authored
commit 23375b13 upstream. While commit 11c236b8 ("apparmor: add a default null dfa") ensure every profile has a policy.dfa it does not resize the policy.start[] to have entries for every possible start value. Which means PROFILE_MEDIATES is not safe to use on untrusted input. Unforunately commit b9590ad4 ("apparmor: remove POLICY_MEDIATES_SAFE") did not take into account the start value usage. The input string in profile_query_cb() is user controlled and is not properly checked to be within the limited start[] entries, even worse it can't be as userspace policy is allowed to make us of entries types the kernel does not know about. This mean usespace can currently cause the kernel to access memory up to 240 entries beyond the start array bounds. Cc: stable@vger.kernel.org Fixes: b9590ad4 ("apparmor: remove POLICY_MEDIATES_SAFE") Signed-off-by:
-
Daniel Smith authored
commit 0e658060 upstream. On Chuwi Hi10 Plus, the Silead device id is MSSL0017. Signed-off-by:
Daniel Smith <danct12@disroot.org> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
