- 19 Jun, 2019 40 commits
-
-
Christoph Hellwig authored
[ Upstream commit 3f98bcc5 ] We already have a proper stub if lightnvm is not enabled, so don't bother with the ifdef. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Christoph Hellwig authored
[ Upstream commit 100c815c ] If we can't get a namespace don't leak the SRCU lock. nvme_ioctl was working around this, but nvme_pr_command wasn't handling this properly. Just do what callers would usually expect. Signed-off-by:
-
Keith Busch authored
[ Upstream commit e43269e6 ] If a controller disabling didn't start a freeze, don't wait for the operation to complete. Reviewed-by:
Ming Lei <ming.lei@redhat.com> Reviewed-by:
-
Alexei Starovoitov authored
[ Upstream commit 7ed4b4e6 ] Fix bpf_get_current_task() declaration. Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Yonghong Song authored
[ Upstream commit ac4e0e05 ] For a host which has a lower rlimit for max locked memory (e.g., 64KB), the following error occurs in one of our production systems: # /usr/sbin/bpftool prog load /paragon/pods/52877437/home/mark.o \ /sys/fs/bpf/paragon_mark_21 type cgroup/skb \ map idx 0 pinned /sys/fs/bpf/paragon_map_21 libbpf: Error in bpf_object__probe_name():Operation not permitted(1). Couldn't load basic 'r0 = 0' BPF program. Error: failed to open object file The reason is due to low locked memory during bpf_object__probe_name() which probes whether program name is supported in kernel or not during __bpf_object__open_xattr(). bpftool program load already tries to relax mlock rlimit before bpf_object__load(). Let us move set_max_rlimit() before __bpf_object__open_xattr(), which fixed the issue here. Fixes: 47eff617 ("bpf, libbpf: introduce bpf_object__probe_caps to test BPF capabilities") Signed-off-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
-
Mark Rutland authored
[ Upstream commit 7ba36ecc ] The arm64 ptdump code can race with concurrent modification of the kernel page tables. At the time this was added, this was sound as: * Modifications to leaf entries could result in stale information being logged, but would not result in a functional problem. * Boot time modifications to non-leaf entries (e.g. freeing of initmem) were performed when the ptdump code cannot be invoked. * At runtime, modifications to non-leaf entries only occurred in the vmalloc region, and these were strictly additive, as intermediate entries were never freed. However, since commit: commit 324420bf ("arm64: add support for ioremap() block mappings") ... it has been possible to create huge mappings in the vmalloc area at runtime, and as part of this existing intermediate levels of table my be removed and freed. It's possible for the ptdump code to race with this, and continue to walk tables which have been freed (and potentially poisoned or reallocated). As a result of this, the ptdump code may dereference bogus addresses, which could be fatal. Since huge-vmap is a TLB and memory optimization, we can disable it when the runtime ptdump code is in use to avoid this problem. Cc: Catalin Marinas <catalin.marinas@arm.com> Fixes: 324420bf ("arm64: add support for ioremap() block mappings") Acked-by:
Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
John Fastabend authored
[ Upstream commit 5fa2ca7c ] The tcp_bpf_wait_data() routine needs to check timeo != 0 before calling sk_wait_event() otherwise we may see unexpected stalls on receiver. Arika did all the leg work here I just formatted, posted and ran a few tests. Fixes: 604326b4 ("bpf, sockmap: convert to generic sk_msg interface") Reported-by:
Arika Chen <eaglesora@gmail.com> Suggested-by:
John Fastabend <john.fastabend@gmail.com> Signed-off-by:
-
Claudiu Manoil authored
[ Upstream commit f4a0be84 ] For the unlikely case of TxBD extensions (i.e. ptp) the driver tries to unmap the tx_swbd corresponding to the extension, which is bogus as it has no buffer attached. Signed-off-by:
Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Luca Ceresoli authored
[ Upstream commit f413cbb3 ] Errors are negative numbers. Using %u shows them as very large positive numbers such as 4294967277 that don't make sense. Use the %d format instead, and get a much nicer -19. Signed-off-by:
Luca Ceresoli <luca@lucaceresoli.net> Fixes: b48e0bab ("net: macb: Migrate to devm clock interface") Fixes: 93b31f48 ("net/macb: unify clock management") Fixes: 421d9df0 ("net/macb: merge at91_ether driver into macb driver") Fixes: aead88bd ("net: ethernet: macb: Add support for rx_clk") Fixes: f5473d1d ("net: macb: Support clock management for tsu_clk") Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 48caebf7 ] When dumping the page table in response to an unexpected kernel page fault, we print the virtual (hashed) address of the page table base, but display physical addresses for everything else. Make the page table dumping code in show_pte() consistent, by printing the page table base pointer as a physical address. Reported-by:
-
James Smart authored
[ Upstream commit c8cb261a ] There was a missing qualification of a valid ndlp structure when calling to send an RRQ for an abort. Add the check. Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Tested-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
James Smart authored
[ Upstream commit 79080d34 ] Many of the exit cases were not releasing the rcu read lock. Corrected the exit paths. Signed-off-by:
-
James Smart authored
[ Upstream commit e2a8be56 ] There were a number of erroneous comments and incorrect older lockdep checks that were causing a number of warnings. Resolve the following: - Inconsistent lock state warnings in lpfc_nvme_info_show(). - Fixed comments and code on sequences where ring lock is now held instead of hbalock. - Reworked calling sequences around lpfc_sli_iocbq_lookup(). Rather than locking prior to the routine and have routine guess on what lock, take the lock within the routine. The lockdep check becomes unnecessary. - Fixed comments and removed erroneous hbalock checks. Signed-off-by:
-
YueHaibing authored
[ Upstream commit d0adee5d ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/qedi/qedi_iscsi.c: In function 'qedi_ep_connect': drivers/scsi/qedi/qedi_iscsi.c:813:23: warning: variable 'udev' set but not used [-Wunused-but-set-variable] drivers/scsi/qedi/qedi_iscsi.c:812:18: warning: variable 'cdev' set but not used [-Wunused-but-set-variable] These have never been used since introduction. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Manish Rangankar <mrangankar@marvell.com> Signed-off-by:
-
YueHaibing authored
[ Upstream commit c09581a5 ] KASAN reports this: BUG: KASAN: global-out-of-bounds in qedi_dbg_err+0xda/0x330 [qedi] Read of size 31 at addr ffffffffc12b0ae0 by task syz-executor.0/2429 CPU: 0 PID: 2429 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xfa/0x1ce lib/dump_stack.c:113 print_address_description+0x1c4/0x270 mm/kasan/report.c:187 kasan_report+0x149/0x18d mm/kasan/report.c:317 memcpy+0x1f/0x50 mm/kasan/common.c:130 qedi_dbg_err+0xda/0x330 [qedi] ? 0xffffffffc12d0000 qedi_init+0x118/0x1000 [qedi] ? 0xffffffffc12d0000 ? 0xffffffffc12d0000 ? 0xffffffffc12d0000 do_one_initcall+0xfa/0x5ca init/main.c:887 do_init_module+0x204/0x5f6 kernel/module.c:3460 load_module+0x66b2/0x8570 kernel/module.c:3808 __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902 do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f2d57e55c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000000000073bfa0 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 00000000200003c0 RDI: 0000000000000003 RBP: 00007f2d57e55c70 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2d57e566bc R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004 The buggy address belongs to the variable: __func__.67584+0x0/0xffffffffffffd520 [qedi] Memory state around the buggy address: ffffffffc12b0980: fa fa fa fa 00 04 fa fa fa fa fa fa 00 00 05 fa ffffffffc12b0a00: fa fa fa fa 00 00 04 fa fa fa fa fa 00 05 fa fa > ffffffffc12b0a80: fa fa fa fa 00 06 fa fa fa fa fa fa 00 02 fa fa ^ ffffffffc12b0b00: fa fa fa fa 00 00 04 fa fa fa fa fa 00 00 03 fa ffffffffc12b0b80: fa fa fa fa 00 00 02 fa fa fa fa fa 00 00 04 fa Currently the qedi_dbg_* family of functions can overrun the end of the source string if it is less than the destination buffer length because of the use of a fixed sized memcpy. Remove the memset/memcpy calls to nfunc and just use func instead as it is always a null terminated string. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: ace7f46b ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Quinn Tran authored
[ Upstream commit 5386a4e6 ] During EEH error recovery testing it was discovered that driver's reset() callback partially frees resources used by driver, leaving some stale memory. After reset() is done and when resume() callback in driver uses old data which results into error leaving adapter disabled due to PCIe error. This patch does cleanup for EEH recovery code path and prevents adapter from getting disabled. Signed-off-by:
Quinn Tran <qutran@marvell.com> Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
John Fastabend authored
[ Upstream commit cabede8b ] When converting a skb to msg->sg we forget to set the size after the latest ktls/tls code conversion. This patch can be reached by doing a redir into ingress path from BPF skb sock recv hook. Then trying to read the size fails. Fix this by setting the size. Fixes: 604326b4 ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by:
-
John Fastabend authored
[ Upstream commit c42253cc ] In tcp bpf remove we free the cork list and purge the ingress msg list. However we do this before the ref count reaches zero so it could be possible some other access is in progress. In this case (tcp close and/or tcp_unhash) we happen to also hold the sock lock so no path exists but lets fix it otherwise it is extremely fragile and breaks the reference counting rules. Also we already check the cork list and ingress msg queue and free them once the ref count reaches zero so its wasteful to check twice. Fixes: 604326b4 ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by:
-
John Fastabend authored
[ Upstream commit 01489436 ] If we try to call strp_done on a parser that has never been initialized, because the sockmap user is only using TX side for example we get the following error. [ 883.422081] WARNING: CPU: 1 PID: 208 at kernel/workqueue.c:3030 __flush_work+0x1ca/0x1e0 ... [ 883.422095] Workqueue: events sk_psock_destroy_deferred [ 883.422097] RIP: 0010:__flush_work+0x1ca/0x1e0 This had been wrapped in a 'if (psock->parser.enabled)' logic which was broken because the strp_done() was never actually being called because we do a strp_stop() earlier in the tear down logic will set parser.enabled to false. This could result in a use after free if work was still in the queue and was resolved by the patch here, 1d79895a ("sk_msg: Always cancel strp work before freeing the psock"). However, calling strp_stop(), done by the patch marked in the fixes tag, only is useful if we never initialized a strp parser program and never initialized the strp to start with. Because if we had initialized a stream parser strp_stop() would have been called by sk_psock_drop() earlier in the tear down process. By forcing the strp to stop we get past the WARNING in strp_done that checks the stopped flag but calling cancel_work_sync on work that has never been initialized is also wrong and generates the warning above. To fix check if the parser program exists. If the program exists then the strp work has been initialized and must be sync'd and cancelled before free'ing any structures. If no program exists we never initialized the stream parser in the first place so skip the sync/cancel logic implemented by strp_done. Finally, remove the strp_done its not needed and in the case where we are using the stream parser has already been called. Fixes: e8e34377 ("bpf: Stop the psock parser before canceling its work") Signed-off-by:
-
Will Deacon authored
[ Upstream commit 14ae42a6 ] Since commit 5768402f ("perf/ring_buffer: Use high order allocations for AUX buffers optimistically"), the perf core tends to back aux buffer allocations with high-order pages with the order encoded in the PagePrivate data. The Arm SPE driver explicitly rejects such pages, causing the perf tool to fail with: | failed to mmap with 12 (Cannot allocate memory) In actual fact, we can simply treat these pages just like any other since the perf core takes care to populate the page array appropriately. In theory we could try to map with PMDs where possible, but for now, let's just get things working again. Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Fixes: 5768402f ("perf/ring_buffer: Use high order allocations for AUX buffers optimistically") Reported-by:
Hanjun Guo <guohanjun@huawei.com> Tested-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Randall Huang authored
[ Upstream commit 2777e654 ] When we traverse xattr entries via __find_xattr(), if the raw filesystem content is faked or any hardware failure occurs, out-of-bound error can be detected by KASAN. Fix the issue by introducing boundary check. [ 38.402878] c7 1827 BUG: KASAN: slab-out-of-bounds in f2fs_getxattr+0x518/0x68c [ 38.402891] c7 1827 Read of size 4 at addr ffffffc0b6fb35dc by task [ 38.402935] c7 1827 Call trace: [ 38.402952] c7 1827 [<ffffff900809003c>] dump_backtrace+0x0/0x6bc [ 38.402966] c7 1827 [<ffffff9008090030>] show_stack+0x20/0x2c [ 38.402981] c7 1827 [<ffffff900871ab10>] dump_stack+0xfc/0x140 [ 38.402995] c7 1827 [<ffffff9008325c40>] print_address_description+0x80/0x2d8 [ 38.403009] c7 1827 [<ffffff900832629c>] kasan_report_error+0x198/0x1fc [ 38.403022] c7 1827 [<ffffff9008326104>] kasan_report_error+0x0/0x1fc [ 38.403037] c7 1827 [<ffffff9008325000>] __asan_load4+0x1b0/0x1b8 [ 38.403051] c7 1827 [<ffffff90085fcc44>] f2fs_getxattr+0x518/0x68c [ 38.403066] c7 1827 [<ffffff90085fc508>] f2fs_xattr_generic_get+0xb0/0xd0 [ 38.403080] c7 1827 [<ffffff9008395708>] __vfs_getxattr+0x1f4/0x1fc [ 38.403096] c7 1827 [<ffffff9008621bd0>] inode_doinit_with_dentry+0x360/0x938 [ 38.403109] c7 1827 [<ffffff900862d6cc>] selinux_d_instantiate+0x2c/0x38 [ 38.403123] c7 1827 [<ffffff900861b018>] security_d_instantiate+0x68/0x98 [ 38.403136] c7 1827 [<ffffff9008377db8>] d_splice_alias+0x58/0x348 [ 38.403149] c7 1827 [<ffffff900858d16c>] f2fs_lookup+0x608/0x774 [ 38.403163] c7 1827 [<ffffff900835eacc>] lookup_slow+0x1e0/0x2cc [ 38.403177] c7 1827 [<ffffff9008367fe0>] walk_component+0x160/0x520 [ 38.403190] c7 1827 [<ffffff9008369ef4>] path_lookupat+0x110/0x2b4 [ 38.403203] c7 1827 [<ffffff900835dd38>] filename_lookup+0x1d8/0x3a8 [ 38.403216] c7 1827 [<ffffff900835eeb0>] user_path_at_empty+0x54/0x68 [ 38.403229] c7 1827 [<ffffff9008395f44>] SyS_getxattr+0xb4/0x18c [ 38.403241] c7 1827 [<ffffff9008084200>] el0_svc_naked+0x34/0x38 Signed-off-by:
Randall Huang <huangrandall@google.com> [Jaegeuk Kim: Fix wrong ending boundary] Reviewed-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Young Xiao authored
[ Upstream commit b281218a ] There is an out-of-bounds access to "config[len - 1]" array when the variable "len" is zero. See commit dada6a43 ("kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var()") for details. Signed-off-by:
Young Xiao <YangX92@hotmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit f0654ba9 ] This reverts commit feb68902. The fix attempt was incorrect, leading to the mutex deadlock through the close of OSS sequencer client. The proper fix needs more consideration, so let's revert it now. Fixes: feb68902 ("ALSA: seq: Protect in-kernel ioctl calls with mutex") Reported-by: syzbot+47ded6c0f23016cde310@syzkaller.appspotmail.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 2eabc5ec ] The snd_seq_ioctl_get_subscription() retrieves the port subscriber information as a pointer, while the object isn't protected, hence it may be deleted before the actual reference. This race was spotted by syzkaller and may lead to a UAF. The fix is simply copying the data in the lookup function that performs in the rwsem to protect against the deletion. Reported-by: syzbot+9437020c82413d00222d@syzkaller.appspotmail.com Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit feb68902 ] ALSA OSS sequencer calls the ioctl function indirectly via snd_seq_kernel_client_ctl(). While we already applied the protection against races between the normal ioctls and writes via the client's ioctl_mutex, this code path was left untouched. And this seems to be the cause of still remaining some rare UAF as spontaneously triggered by syzkaller. For the sake of robustness, wrap the ioctl_mutex also for the call via snd_seq_kernel_client_ctl(), too. Reported-by: syzbot+e4c8abb920efa77bace9@syzkaller.appspotmail.com Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit 40ea9729 ] New tooling noticed this mishap: kernel/kcov.o: warning: objtool: write_comp_data()+0x138: call to __stack_chk_fail() with UACCESS enabled kernel/kcov.o: warning: objtool: __sanitizer_cov_trace_pc()+0xd9: call to __stack_chk_fail() with UACCESS enabled All the other instrumentation (KASAN,UBSAN) also have stack protector disabled. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Lucas De Marchi authored
commit 326fb6dd upstream. While loading the DMC firmware we were double checking the headers made sense, but in no place we checked that we were actually reading memory we were supposed to. This could be wrong in case the firmware file is truncated or malformed. Before this patch: # ls -l /lib/firmware/i915/icl_dmc_ver1_07.bin -rw-r--r-- 1 root root 25716 Feb 1 12:26 icl_dmc_ver1_07.bin # truncate -s 25700 /lib/firmware/i915/icl_dmc_ver1_07.bin # modprobe i915 # dmesg| grep -i dmc [drm:intel_csr_ucode_init [i915]] Loading i915/icl_dmc_ver1_07.bin [drm] Finished loading DMC firmware i915/icl_dmc_ver1_07.bin (v1.7) i.e. it loads random data. Now it fails like below: [drm:intel_csr_ucode_init [i915]] Loading i915/icl_dmc_ver1_07.bin [drm:csr_load_work_fn [i915]] *ERROR* Truncated DMC firmware, rejecting. i915 0000:00:02.0: Failed to load DMC firmware i915/icl_dmc_ver1_07.bin. Disabling runtime power management. i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 Before reading any part of the firmware file, validate the input first. Fixes: eb805623 ("drm/i915/skl: Add support to load SKL CSR firmware.") Cc: stable@vger.kernel.org Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190605235535.17791-1-lucas.demarchi@intel.com (cherry picked from commit bc7b488b) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
commit 77ce94db upstream. We forgot to set .has_alpha=true for the A+CCS formats when the code started to consult .has_alpha. This manifests as A+CCS being treated as X+CCS which means no per-pixel alpha blending. Fix the format list appropriately. Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Heinrich Fink <heinrich.fink@daqri.com> Reported-by:
Heinrich Fink <heinrich.fink@daqri.com> Tested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603142500.25680-1-ville.syrjala@linux.intel.comReviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit 38f30041) Signed-off-by:
-
Hans de Goede authored
commit f9a99131 upstream. Prior to this commit we fail to init the DSI panel on the GPD MicroPC: https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/ The problem is intel_dsi_vbt_init() failing with the following error: *ERROR* Burst mode freq is less than computed The pclk in the VBT panel modeline is 70000, together with 24 bpp and 4 lines this results in a bitrate value of 70000 * 24 / 4 = 420000. But the target_burst_mode_freq in the VBT is 418000. This commit works around this problem by adding an intel_fuzzy_clock_check when target_burst_mode_freq < bitrate and setting target_burst_mode_freq to bitrate when that checks succeeds, fixing the panel not working. Cc: stable@vger.kernel.org Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190524174028.21659-2-hdegoede@redhat.com (cherry picked from commit 2c1c5525) Signed-off-by:
-
Ville Syrjälä authored
commit d74408f5 upstream. Our SDVO audio support is pretty bogus. We can't push audio over the SDVO bus, so trying to enable audio in the SDVO control register doesn't do anything. In fact it looks like the SDVO encoder will always mix in the audio coming over HDA, and there's no (at least documented) way to disable that from our side. So HDMI audio does work currently on gen4 but only by luck really. On gen3 it got broken by the referenced commit. And what has always been missing on every platform is the ELD. To pass the ELD to the audio driver we need to write it to magic buffer in the SDVO encoder hardware which then gets pulled out via HDA in the other end. Ie. pretty much the same thing we had for native HDMI before we started to just pass the ELD between the drivers. This sort of explains why we even have that silly hardware buffer with native HDMI. $ cat /proc/asound/card0/eld#1.0 -monitor_present 0 -eld_valid 0 +monitor_present 1 +eld_valid 1 +monitor_name LG TV +connection_type HDMI +... This also fixes our state readout since we can now query the SDVO encoder about the state of the "ELD valid" and "presence detect" bits. As mentioned those don't actually control whether audio gets sent over the HDMI cable, but it's the best we can do. And with the state checker appeased we can re-enable HDMI audio for gen3. Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: zardam@gmail.com Tested-by: zardam@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108976 Fixes: de44e256 ("drm/i915/sdvo: Shut up state checker with hdmi cards on gen3") Signed-off-by:
Imre Deak <imre.deak@intel.com> (cherry picked from commit dc49a56b) Signed-off-by:
-
Shirish S authored
commit 517b91f4 upstream. [What] readptr read always returns zero, since most likely these blocks are either power or clock gated. [How] fetch rptr after amdgpu_ring_alloc() which informs the power management code that the block is about to be used and hence the gating is turned off. Signed-off-by:
Louis Li <Ching-shih.Li@amd.com> Signed-off-by:
Shirish S <shirish.s@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Kuninori Morimoto authored
commit 29040d1a upstream. commit 53e947a0 ("ASoC: soc-core: merge card resources cleanup method") merged cleanup method of snd_soc_instantiate_card() and soc_cleanup_card_resources(). But, after this commit, if user uses unbind/bind to Component factor drivers, Kernel might indicates refcount error at soc_cleanup_card_resources(). The 1st reason is card->snd_card is still exist even though snd_card_free() was called, but it is already cleaned. We need to set NULL to it. 2nd is card->dapm and card create debugfs, but its dentry is still exist even though it was removed. We need to set NULL to it. Fixes: 53e947a0 ("ASoC: soc-core: merge card resources cleanup method") Cc: stable@vger.kernel.org # for v5.1 Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
S.j. Wang authored
commit b06c58c2 upstream. When the output sample rate is [8kHz, 30kHz], the limitation of the supported ratio range is [1/24, 8]. In the driver we use (8kHz, 30kHz) instead of [8kHz, 30kHz]. So this patch is to fix this issue and the potential rounding issue with divider. Fixes: fff6e03c ("ASoC: fsl_asrc: add support for 8-30kHz output sample rate") Cc: <stable@vger.kernel.org> Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by:
Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by:
-
S.j. Wang authored
commit ad6eecbf upstream. Add regcache_mark_dirty before regcache_sync for power of codec may be lost at suspend, then all the register need to be reconfigured. Fixes: 0c516b4f ("ASoC: cs42xx8: Add codec driver support for CS42448/CS42888") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Tejun Heo authored
commit 18fa84a2 upstream. A PF_EXITING task can stay associated with an offline css. If such task calls task_get_css(), it can get stuck indefinitely. This can be triggered by BSD process accounting which writes to a file with PF_EXITING set when racing against memcg disable as in the backtrace at the end. After this change, task_get_css() may return a css which was already offline when the function was called. None of the existing users are affected by this change. INFO: rcu_sched self-detected stall on CPU INFO: rcu_sched detected stalls on CPUs/tasks: ... NMI backtrace for cpu 0 ... Call Trace: <IRQ> dump_stack+0x46/0x68 nmi_cpu_backtrace.cold.2+0x13/0x57 nmi_trigger_cpumask_backtrace+0xba/0xca rcu_dump_cpu_stacks+0x9e/0xce rcu_check_callbacks.cold.74+0x2af/0x433 update_process_times+0x28/0x60 tick_sched_timer+0x34/0x70 __hrtimer_run_queues+0xee/0x250 hrtimer_interrupt+0xf4/0x210 smp_apic_timer_interrupt+0x56/0x110 apic_timer_interrupt+0xf/0x20 </IRQ> RIP: 0010:balance_dirty_pages_ratelimited+0x28f/0x3d0 ... btrfs_file_write_iter+0x31b/0x563 __vfs_write+0xfa/0x140 __kernel_write+0x4f/0x100 do_acct_process+0x495/0x580 acct_process+0xb9/0xdb do_exit+0x748/0xa00 do_group_exit+0x3a/0xa0 get_signal+0x254/0x560 do_signal+0x23/0x5c0 exit_to_usermode_loop+0x5d/0xa0 prepare_exit_to_usermode+0x53/0x80 retint_user+0x8/0x8 Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org # v4.2+ Fixes: ec438699 ("cgroup, block: implement task_get_css() and use it in bio_associate_current()") Signed-off-by:
-
Coly Li authored
commit 1f0ffa67 upstream. When people set a writeback percent via sysfs file, /sys/block/bcache<N>/bcache/writeback_percent current code directly sets BCACHE_DEV_WB_RUNNING to dc->disk.flags and schedules kworker dc->writeback_rate_update. If there is no cache set attached to, the writeback kernel thread is not running indeed, running dc->writeback_rate_update does not make sense and may cause NULL pointer deference when reference cache set pointer inside update_writeback_rate(). This patch checks whether the cache set point (dc->disk.c) is NULL in sysfs interface handler, and only set BCACHE_DEV_WB_RUNNING and schedule dc->writeback_rate_update when dc->disk.c is not NULL (it means the cache device is attached to a cache set). This problem might be introduced from initial bcache commit, but commit 3fd47bfe ("bcache: stop dc->writeback_rate_update properly") changes part of the original code piece, so I add 'Fixes: 3fd47bfe' to indicate from which commit this patch can be applied. Fixes: 3fd47bfe ("bcache: stop dc->writeback_rate_update properly") Reported-by:
Bjørn Forsman <bjorn.forsman@gmail.com> Signed-off-by:
Coly Li <colyli@suse.de> Reviewed-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Coly Li authored
commit 31b90956 upstream. Recently people report bcache code compiled with gcc9 is broken, one of the buggy behavior I observe is that two adjacent 4KB I/Os should merge into one but they don't. Finally it turns out to be a stack corruption caused by macro PRECEDING_KEY(). See how PRECEDING_KEY() is defined in bset.h, 437 #define PRECEDING_KEY(_k) \ 438 ({ \ 439 struct bkey *_ret = NULL; \ 440 \ 441 if (KEY_INODE(_k) || KEY_OFFSET(_k)) { \ 442 _ret = &KEY(KEY_INODE(_k), KEY_OFFSET(_k), 0); \ 443 \ 444 if (!_ret->low) \ 445 _ret->high--; \ 446 _ret->low--; \ 447 } \ 448 \ 449 _ret; \ 450 }) At line 442, _ret points to address of a on-stack variable combined by KEY(), the life range of this on-stack variable is in line 442-446, once _ret is returned to bch_btree_insert_key(), the returned address points to an invalid stack address and this address is overwritten in the following called bch_btree_iter_init(). Then argument 'search' of bch_btree_iter_init() points to some address inside stackframe of bch_btree_iter_init(), exact address depends on how the compiler allocates stack space. Now the stack is corrupted. Fixes: 0eacac22 ("bcache: PRECEDING_KEY()") Signed-off-by:
Rolf Fokkens <rolf@rolffokkens.nl> Reviewed-by:
Pierre JUHEN <pierre.juhen@orange.fr> Tested-by:
Shenghui Wang <shhuiw@foxmail.com> Tested-by:
-
Russell King authored
commit ca21f851 upstream. The Acorn i2c driver (for RiscPC) triggers the "i2c adapter has no name" warning in the I2C core driver, resulting in the RTC being inaccessible. Fix this. Fixes: 2236baa7 ("i2c: Sanity checks on adapter registration") Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org Signed-off-by:
-
Casey Schaufler authored
commit 6e7739fc upstream. The 5.1 mount system rework changed the smackfsdef mount option to smackfsdefault. This fixes the regression by making smackfsdef treated the same way as smackfsdefault. Also fix the smack_param_specs[] to have "smack" prefixes on all the names. This isn't visible to a user unless they either: (a) Try to mount a filesystem that's converted to the internal mount API and that implements the ->parse_monolithic() context operation - and only then if they call security_fs_context_parse_param() rather than security_sb_eat_lsm_opts(). There are no examples of this upstream yet, but nfs will probably want to do this for nfs2 or nfs3. (b) Use fsconfig() to configure the filesystem - in which case security_fs_context_parse_param() will be called. This issue is that smack_sb_eat_lsm_opts() checks for the "smack" prefix on the options, but smack_fs_context_parse_param() does not. Fixes: c3300aaf ("smack: get rid of match_token()") Fixes: 2febd254 ("smack: Implement filesystem context security hooks") Cc: stable@vger.kernel.org Reported-by:
Jose Bollo <jose.bollo@iot.bzh> Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
David Howells <dhowells@redhat.com> Tested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Robin Murphy authored
commit 4e4abae3 upstream. Apparently, some Qualcomm arm64 platforms which appear to expose their SMMU global register space are still, in fact, using a hypervisor to mediate it by trapping and emulating register accesses. Sadly, some deployed versions of said trapping code have bugs wherein they go horribly wrong for stores using r31 (i.e. XZR/WZR) as the source register. While this can be mitigated for GCC today by tweaking the constraints for the implementation of writel_relaxed(), to avoid any potential arms race with future compilers more aggressively optimising register allocation, the simple way is to just remove all the problematic constant zeros. For the write-only TLB operations, the actual value is irrelevant anyway and any old nearby variable will provide a suitable GPR to encode. The one point at which we really do need a zero to clear a context bank happens before any of the TLB maintenance where crashes have been reported, so is apparently not a problem... :/ Reported-by:
AngeloGioacchino Del Regno <kholk11@gmail.com> Tested-by:
Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
