- Jul 19, 2021
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210715182448.393443551@linuxfoundation.org Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Link: https://lore.kernel.org/r/20210716182029.878765454@linuxfoundation.org Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Hulk Robot <hulkrobot@huawei.com> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tetsuo Handa authored
commit 49ec114a upstream. Oops, I failed to update subject line. From 07571157c91b98ce1a4aa70967531e64b78e8346 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Date: Mon, 12 Apr 2021 22:25:06 +0900 Subject: smackfs: restrict bytes count in smk_set_cipso() Commit 7ef4c19d ("smackfs: restrict bytes count in smackfs write functions") missed that count > SMK_CIPSOMAX check applies to only format == SMK_FIXED24_FMT case. Reported-by:
syzbot <syzbot+77c53db50c9fff774e8e@syzkaller.appspotmail.com> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
-
Pavel Skripkin authored
commit 9d574f98 upstream. Avoid passing inode with JFS_SBI(inode->i_sb)->ipimap == NULL to diFree()[1]. GFP will appear: struct inode *ipimap = JFS_SBI(ip->i_sb)->ipimap; struct inomap *imap = JFS_IP(ipimap)->i_imap; JFS_IP() will return invalid pointer when ipimap == NULL Call Trace: diFree+0x13d/0x2dc0 fs/jfs/jfs_imap.c:853 [1] jfs_evict_inode+0x2c9/0x370 fs/jfs/inode.c:154 evict+0x2ed/0x750 fs/inode.c:578 iput_final fs/inode.c:1654 [inline] iput.part.0+0x3fe/0x820 fs/inode.c:1680 iput+0x58/0x70 fs/inode.c:1670 Reported-and-tested-by:
<syzbot+0a89a7b56db04c21a656@syzkaller.appspotmail.com> Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by:
-
Zou Wei authored
commit 884af72c upstream. Add the missing unlock before return from function mcp23s08_irq() in the error handling case. v1-->v2: remove the "return IRQ_HANDLED" line Fixes: 897120d4 ("pinctrl: mcp23s08: fix race condition in irq handler") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Link: https://lore.kernel.org/r/1623134048-56051-1-git-send-email-zou_wei@huawei.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Benjamin Drung authored
commit 4c6e0976 upstream. The Elgato Cam Link 4K HDMI video capture card reports to support three different pixel formats, where the first format depends on the connected HDMI device. ``` $ v4l2-ctl -d /dev/video0 --list-formats-ext ioctl: VIDIOC_ENUM_FMT Type: Video Capture [0]: 'NV12' (Y/CbCr 4:2:0) Size: Discrete 3840x2160 Interval: Discrete 0.033s (29.970 fps) [1]: 'NV12' (Y/CbCr 4:2:0) Size: Discrete 3840x2160 Interval: Discrete 0.033s (29.970 fps) [2]: 'YU12' (Planar YUV 4:2:0) Size: Discrete 3840x2160 Interval: Discrete 0.033s (29.970 fps) ``` Changing the pixel format to anything besides the first pixel format does not work: ``` $ v4l2-ctl -d /dev/video0 --try-fmt-video pixelformat=YU12 Format Video Capture: Width/Height : 3840/2160 Pixel Format : 'NV12' (Y/CbCr 4:2:0) Field : None Bytes per Line : 3840 Size Image : 12441600 Colorspace : sRGB Transfer Function : Rec. 709 YCbCr/HSV Encoding: Rec. 709 Quantization : Default (maps to Limited Range) Flags : ``` User space applications like VLC might show an error message on the terminal in that case: ``` libv4l2: error set_fmt gave us a different result than try_fmt! ``` Depending on the error handling of the user space applications, they might display a distorted video, because they use the wrong pixel format for decoding the stream. The Elgato Cam Link 4K responds to the USB video probe VS_PROBE_CONTROL/VS_COMMIT_CONTROL with a malformed data structure: The second byte contains bFormatIndex (instead of being the second byte of bmHint). The first byte is always zero. The third byte is always 1. The firmware bug was reported to Elgato on 2020-12-01 and it was forwarded by the support team to the developers as feature request. There is no firmware update available since then. The latest firmware for Elgato Cam Link 4K as of 2021-03-23 has MCU 20.02.19 and FPGA 67. Therefore correct the malformed data structure for this device. The change was successfully tested with VLC, OBS, and Chromium using different pixel formats (YUYV, NV12, YU12), resolutions (3840x2160, 1920x1080), and frame rates (29.970 and 59.940 fps). Cc: stable@vger.kernel.org Signed-off-by:
Benjamin Drung <bdrung@posteo.de> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit b4bb4d42 upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Control transfers without a data stage are treated as OUT requests by the USB stack and should be using usb_sndctrlpipe(). Failing to do so will now trigger a warning. Fix the single zero-length control request which was using the read-register helper, and update the helper so that zero-length reads fail with an error message instead. Fixes: 6a7eba24 ("V4L/DVB (8157): gspca: all subdrivers") Cc: stable@vger.kernel.org # 2.6.27 Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Johan Hovold authored
commit 53ae298f upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the USB_REQ_SYNCH_FRAME request which erroneously used usb_sndctrlpipe(). Fixes: 27d35fc3 ("V4L/DVB (10639): gspca - sq905: New subdriver.") Cc: stable@vger.kernel.org # 2.6.30 Signed-off-by:
-
Pavel Skripkin authored
commit 0a045eac upstream. syzbot reported memory leak in zr364xx driver. The problem was in non-freed urb in case of usb_submit_urb() fail. backtrace: [<ffffffff82baedf6>] kmalloc include/linux/slab.h:561 [inline] [<ffffffff82baedf6>] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [<ffffffff82f7cce8>] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022 [<ffffffff84251dfc>] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline] [<ffffffff84251dfc>] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516 [<ffffffff82bb6507>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<ffffffff826018a9>] really_probe+0x159/0x500 drivers/base/dd.c:576 Fixes: ccbf035a ("V4L/DVB (12278): zr364xx: implement V4L2_CAP_STREAMING") Cc: stable@vger.kernel.org Reported-by:
<syzbot+af4fa391ef18efdd5f69@syzkaller.appspotmail.com> Signed-off-by:
-
Johan Hovold authored
commit 8c8b9a9b upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the control requests which erroneously used usb_rcvctrlpipe(). Fixes: 8466028b ("V4L/DVB (8734): Initial support for AME DTV-5100 USB2.0 DVB-T") Cc: stable@vger.kernel.org # 2.6.28 Signed-off-by:
-
Arnd Bergmann authored
commit 0a7790be upstream. The saa6588_ioctl() function expects to get called from other kernel functions with a 'saa6588_command' pointer, but I found nothing stops it from getting called from user space instead, which seems rather dangerous. The same thing happens in the davinci vpbe driver with its VENC_GET_FLD command. As a quick fix, add a separate .command() callback pointer for this driver and change the two callers over to that. This change can easily get backported to stable kernels if necessary, but since there are only two drivers, we may want to eventually replace this with a set of more specialized callbacks in the long run. Fixes: c3fda7f8 ("V4L/DVB (10537): saa6588: convert to v4l2_subdev.") Cc: stable@vger.kernel.org Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Pali Rohár authored
commit 7f71a409 upstream. Marvell Armada 3700 Functional Errata, Guidelines, and Restrictions document describes in erratum 4.1 PCIe value of vendor ID (Ref #: 243): The readback value of VEND_ID (RD0070000h [15:0]) is 1B4Bh, while it should read 11ABh. The firmware can write the correct value, 11ABh, through VEND_ID (RD0076044h [15:0]). Implement this workaround in aardvark driver for both PCI vendor id and PCI subsystem vendor id. This change affects and fixes PCI vendor id of emulated PCIe root bridge. After this change emulated PCIe root bridge has correct vendor id. Link: https://lore.kernel.org/r/20210624222621.4776-5-pali@kernel.org Fixes: 8a3ebd8d ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by:
Pali Rohár <pali@kernel.org> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by:
Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Pali Rohár authored
commit 8ceeac30 upstream. PIO_NON_POSTED_REQ for PIO_STAT register is incorrectly defined. Bit 10 in register PIO_STAT indicates the response is to a non-posted request. Link: https://lore.kernel.org/r/20210624213345.3617-2-pali@kernel.org Signed-off-by:
-
Konstantin Kharlamov authored
commit 4694ae37 upstream. On Macbook 2013, resuming from suspend-to-idle or standby resulted in the external monitor no longer being detected, a stacktrace, and errors like this in dmesg: pcieport 0000:06:00.0: can't change power state from D3hot to D0 (config space inaccessible) The reason is that we know how to turn power to the Thunderbolt controller *off* via the SXIO/SXFP/SXLF methods, but we don't know how to turn power back on. We have to rely on firmware to turn the power back on. When going to the "suspend-to-idle" or "standby" system sleep states, firmware is not involved either on the suspend side or the resume side, so we can't use SXIO/SXFP/SXLF to turn the power off. Skip SXIO/SXFP/SXLF when firmware isn't involved in suspend, e.g., when we're going to the "suspend-to-idle" or "standby" system sleep states. Fixes: 1df5172c ("PCI: Suspend/resume quirks for Apple thunderbolt") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212767 Link: https://lore.kernel.org/r/20210520235501.917397-1-Hi-Angel@yandex.ru Signed-off-by:
Konstantin Kharlamov <Hi-Angel@yandex.ru> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org Signed-off-by:
-
Hou Tao authored
commit b6e58b54 upstream. remove_raw() in dm_btree_remove() may fail due to IO read error (e.g. read the content of origin block fails during shadowing), and the value of shadow_spine::root is uninitialized, but the uninitialized value is still assign to new_root in the end of dm_btree_remove(). For dm-thin, the value of pmd->details_root or pmd->root will become an uninitialized value, so if trying to read details_info tree again out-of-bound memory may occur as showed below: general protection fault, probably for non-canonical address 0x3fdcb14c8d7520 CPU: 4 PID: 515 Comm: dmsetup Not tainted 5.13.0-rc6 Hardware name: QEMU Standard PC RIP: 0010:metadata_ll_load_ie+0x14/0x30 Call Trace: sm_metadata_count_is_more_than_one+0xb9/0xe0 dm_tm_shadow_block+0x52/0x1c0 shadow_step+0x59/0xf0 remove_raw+0xb2/0x170 dm_btree_remove+0xf4/0x1c0 dm_pool_delete_thin_device+0xc3/0x140 pool_message+0x218/0x2b0 target_message+0x251/0x290 ctl_ioctl+0x1c4/0x4d0 dm_ctl_ioctl+0xe/0x20 __x64_sys_ioctl+0x7b/0xb0 do_syscall_64+0x40/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixing it by only assign new_root when removal succeeds Signed-off-by:
Hou Tao <houtao1@huawei.com> Cc: stable@vger.kernel.org Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Sai Prakash Ranjan authored
commit 5fae8a94 upstream. commit 6f755e85 ("coresight: Add helper for inserting synchronization packets") removed trailing '\0' from barrier_pkt array and updated the call sites like etb_update_buffer() to have proper checks for barrier_pkt size before read but missed updating tmc_update_etf_buffer() which still reads barrier_pkt past the array size resulting in KASAN out-of-bounds bug. Fix this by adding a check for barrier_pkt size before accessing like it is done in etb_update_buffer(). BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698 Read of size 4 at addr ffffffd05b7d1030 by task perf/2629 Call trace: dump_backtrace+0x0/0x27c show_stack+0x20/0x2c dump_stack+0x11c/0x188 print_address_description+0x3c/0x4a4 __kasan_report+0x140/0x164 kasan_report+0x10/0x18 __asan_report_load4_noabort+0x1c/0x24 tmc_update_etf_buffer+0x4b8/0x698 etm_event_stop+0x248/0x2d8 etm_event_del+0x20/0x2c event_sched_out+0x214/0x6f0 group_sched_out+0xd0/0x270 ctx_sched_out+0x2ec/0x518 __perf_event_task_sched_out+0x4fc/0xe6c __schedule+0x1094/0x16a0 preempt_schedule_irq+0x88/0x170 arm64_preempt_schedule_irq+0xf0/0x18c el1_irq+0xe8/0x180 perf_event_exec+0x4d8/0x56c setup_new_exec+0x204/0x400 load_elf_binary+0x72c/0x18c0 search_binary_handler+0x13c/0x420 load_script+0x500/0x6c4 search_binary_handler+0x13c/0x420 exec_binprm+0x118/0x654 __do_execve_file+0x77c/0xba4 __arm64_compat_sys_execve+0x98/0xac el0_svc_common+0x1f8/0x5e0 el0_svc_compat_handler+0x84/0xb0 el0_svc_compat+0x10/0x50 The buggy address belongs to the variable: barrier_pkt+0x10/0x40 Memory state around the buggy address: ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03 ^ ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa ================================================================== Link: https://lore.kernel.org/r/20210505093430.18445-1-saiprakash.ranjan@codeaurora.org Fixes: 0c3fc4d5 ("coresight: Add barrier packet for synchronisation") Cc: stable@vger.kernel.org Signed-off-by:
Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20210614175901.532683-6-mathieu.poirier@linaro.org Signed-off-by:
-
Lv Yunlong authored
commit 9272e5d0 upstream. In the out_err_bus_register error branch of tpci200_pci_probe, tpci200->info->cfg_regs is freed by tpci200_uninstall()-> tpci200_unregister()->pci_iounmap(..,tpci200->info->cfg_regs) in the first time. But later, iounmap() is called to free tpci200->info->cfg_regs again. My patch sets tpci200->info->cfg_regs to NULL after tpci200_uninstall() to avoid the double free. Fixes: cea2f7cd ("Staging: ipack/bridges/tpci200: Use the TPCI200 in big endian mode") Cc: stable <stable@vger.kernel.org> Acked-by:
Samuel Iglesias Gonsalvez <siglesias@igalia.com> Signed-off-by:
Lv Yunlong <lyl2019@mail.ustc.edu.cn> Link: https://lore.kernel.org/r/20210524093205.8333-1-lyl2019@mail.ustc.edu.cn Signed-off-by:
-
Paul Burton authored
commit 4030a6e6 upstream. Currently tgid_map is sized at PID_MAX_DEFAULT entries, which means that on systems where pid_max is configured higher than PID_MAX_DEFAULT the ftrace record-tgid option doesn't work so well. Any tasks with PIDs higher than PID_MAX_DEFAULT are simply not recorded in tgid_map, and don't show up in the saved_tgids file. In particular since systemd v243 & above configure pid_max to its highest possible 1<<22 value by default on 64 bit systems this renders the record-tgids option of little use. Increase the size of tgid_map to the configured pid_max instead, allowing it to cover the full range of PIDs up to the maximum value of PID_MAX_LIMIT if the system is configured that way. On 64 bit systems with pid_max == PID_MAX_LIMIT this will increase the size of tgid_map from 256KiB to 16MiB. Whilst this 64x increase in memory overhead sounds significant 64 bit systems are presumably best placed to accommodate it, and since tgid_map is only allocated when the record-tgid option is actually used presumably the user would rather it spends sufficient memory to actually record the tgids they expect. The size of tgid_map could also increase for CONFIG_BASE_SMALL=y configurations, but these seem unlikely to be systems upon which people are both configuring a large pid_max and running ftrace with record-tgid anyway. Of note is that we only allocate tgid_map once, the first time that the record-tgid option is enabled. Therefore its size is only set once, to the value of pid_max at the time the record-tgid option is first enabled. If a user increases pid_max after that point, the saved_tgids file will not contain entries for any tasks with pids beyond the earlier value of pid_max. Link: https://lkml.kernel.org/r/20210701172407.889626-2-paulburton@google.com Fixes: d914ba37 ("tracing: Add support for recording tgid of tasks") Cc: Ingo Molnar <mingo@redhat.com> Cc: Joel Fernandes <joelaf@google.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Paul Burton <paulburton@google.com> [ Fixed comment coding style ] Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Paul Burton authored
commit b81b3e95 upstream. The tgid_map array records a mapping from pid to tgid, where the index of an entry within the array is the pid & the value stored at that index is the tgid. The saved_tgids_next() function iterates over pointers into the tgid_map array & dereferences the pointers which results in the tgid, but then it passes that dereferenced value to trace_find_tgid() which treats it as a pid & does a further lookup within the tgid_map array. It seems likely that the intent here was to skip over entries in tgid_map for which the recorded tgid is zero, but instead we end up skipping over entries for which the thread group leader hasn't yet had its own tgid recorded in tgid_map. A minimal fix would be to remove the call to trace_find_tgid, turning: if (trace_find_tgid(*ptr)) into: if (*ptr) ..but it seems like this logic can be much simpler if we simply let seq_read() iterate over the whole tgid_map array & filter out empty entries by returning SEQ_SKIP from saved_tgids_show(). Here we take that approach, removing the incorrect logic here entirely. Link: https://lkml.kernel.org/r/20210630003406.4013668-1-paulburton@google.com Fixes: d914ba37 ("tracing: Add support for recording tgid of tasks") Cc: Ingo Molnar <mingo@redhat.com> Cc: Joel Fernandes <joelaf@google.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jan Kara authored
commit 11c7aa0d upstream. Commit 545fbd07 ("rq-qos: fix missed wake-ups in rq_qos_throttle") tried to fix a problem that a process could be sleeping in rq_qos_wait() without anyone to wake it up. However the fix is not complete and the following can still happen: CPU1 (waiter1) CPU2 (waiter2) CPU3 (waker) rq_qos_wait() rq_qos_wait() acquire_inflight_cb() -> fails acquire_inflight_cb() -> fails completes IOs, inflight decreased prepare_to_wait_exclusive() prepare_to_wait_exclusive() has_sleeper = !wq_has_single_sleeper() -> true as there are two sleepers has_sleeper = !wq_has_single_sleeper() -> true io_schedule() io_schedule() Deadlock as now there's nobody to wakeup the two waiters. The logic automatically blocking when there are already sleepers is really subtle and the only way to make it work reliably is that we check whether there are some waiters in the queue when adding ourselves there. That way, we are guaranteed that at least the first process to enter the wait queue will recheck the waiting condition before going to sleep and thus guarantee forward progress. Fixes: 545fbd07 ("rq-qos: fix missed wake-ups in rq_qos_throttle") CC: stable@vger.kernel.org Signed-off-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20210607112613.25344-1-jack@suse.cz Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Yun Zhou authored
commit d3b16034 upstream. There's two variables being increased in that loop (i and j), and i follows the raw data, and j follows what is being written into the buffer. We should compare 'i' to MAX_MEMHEX_BYTES or compare 'j' to HEX_CHARS. Otherwise, if 'j' goes bigger than HEX_CHARS, it will overflow the destination buffer. Link: https://lore.kernel.org/lkml/20210625122453.5e2fe304@oasis.local.home/ Link: https://lkml.kernel.org/r/20210626032156.47889-1-yun.zhou@windriver.com Cc: stable@vger.kernel.org Fixes: 5e3ca0ec ("ftrace: introduce the "hex" output method") Signed-off-by:
Yun Zhou <yun.zhou@windriver.com> Signed-off-by:
-
Ferry Toth authored
commit ecb5bdff upstream. extcon driver for Basin Cove PMIC shadows the switch status used for dwc3 DRD to detect a change in the switch position. This change initializes the status at probe time. Cc: stable@vger.kernel.org Fixes: 492929c5 ("extcon: mrfld: Introduce extcon driver for Basin Cove PMIC") Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Ferry Toth <ftoth@exalondelft.nl> Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
-
Christophe JAILLET authored
commit 63879e29 upstream. 'for_each_child_of_node' performs an of_node_get on each iteration, so a return from the middle of the loop requires an of_node_put. Fixes: e888d445 ("nvmem: resolve cells from DT at registration time") Cc: <stable@vger.kernel.org> Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210611102321.11509-1-srinivas.kandagatla@linaro.org Signed-off-by:
-
Linus Walleij authored
commit f1c74a6c upstream. Trying to get the AB8500 charging driver working I ran into a bit of bitrot: we haven't used the driver for a while so errors in refactorings won't be noticed. This one is pretty self evident: use argument to the macro or we end up with a random pointer to something else. Cc: stable@vger.kernel.org Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Marcus Cooper <codekipper@gmail.com> Fixes: 297d716f ("power_supply: Change ownership from driver to core") Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Zhihao Cheng authored
commit f4e3634a upstream. UBIFS may occur some problems with concurrent xattr_{set|get} and listxattr operations, such as assertion failure, memory corruption, stale xattr value[1]. Fix it by importing a new rw-lock in @ubifs_inode to serilize write operations on xattr, concurrent read operations are still effective, just like ext4. [1] https://lore.kernel.org/linux-mtd/20200630130438.141649-1-houtao1@huawei.com Fixes: 1e51764a ("UBIFS: add new flash file system") Cc: stable@vger.kernel.org # v2.6+ Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com> Reviewed-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Srinivas Pandruvada authored
commit fe6a6de6 upstream. The following fixes are done for tcc sysfs interface: - TCC is 6 bits only from bit 29-24 - TCC of 0 is valid - When BIT(31) is set, this register is read only - Check for invalid tcc value - Error for negative values Fixes: fdf4f2fb ("drivers: thermal: processor_thermal_device: Export sysfs interface for TCC offset") Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: stable@vger.kernel.org Acked-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210628215803.75038-1-srinivas.pandruvada@linux.intel.com Signed-off-by:
-
Petr Pavlu authored
commit 2253042d upstream. When an IPMI watchdog timer is being stopped in ipmi_close() or ipmi_ioctl(WDIOS_DISABLECARD), the current watchdog action is updated to WDOG_TIMEOUT_NONE and _ipmi_set_timeout(IPMI_SET_TIMEOUT_NO_HB) is called to install this action. The latter function ends up invoking __ipmi_set_timeout() which makes the actual 'Set Watchdog Timer' IPMI request. For IPMI 1.0, this operation results in fully stopping the watchdog timer. For IPMI >= 1.5, function __ipmi_set_timeout() always specifies the "don't stop" flag in the prepared 'Set Watchdog Timer' IPMI request. This causes that the watchdog timer has its action correctly updated to 'none' but the timer continues to run. A problem is that IPMI firmware can then still log an expiration event when the configured timeout is reached, which is unexpected because the watchdog timer was requested to be stopped. The patch fixes this problem by not setting the "don't stop" flag in __ipmi_set_timeout() when the current action is WDOG_TIMEOUT_NONE which results in stopping the watchdog timer. This makes the behaviour for IPMI >= 1.5 consistent with IPMI 1.0. It also matches the logic in __ipmi_heartbeat() which does not allow to reset the watchdog if the current action is WDOG_TIMEOUT_NONE as that would start the timer. Signed-off-by:
Petr Pavlu <petr.pavlu@suse.com> Message-Id: <10a41bdc-9c99-089c-8d89-fa98ce5ea080@suse.com> Cc: stable@vger.kernel.org Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Nathan Chancellor authored
commit fca41af1 upstream. fw_cfg_showrev() is called by an indirect call in kobj_attr_show(), which violates clang's CFI checking because fw_cfg_showrev()'s second parameter is 'struct attribute', whereas the ->show() member of 'struct kobj_structure' expects the second parameter to be of type 'struct kobj_attribute'. $ cat /sys/firmware/qemu_fw_cfg/rev 3 $ dmesg | grep "CFI failure" [ 26.016832] CFI failure (target: fw_cfg_showrev+0x0/0x8): Fix this by converting fw_cfg_rev_attr to 'struct kobj_attribute' where this would have been caught automatically by the incompatible pointer types compiler warning. Update fw_cfg_showrev() accordingly. Fixes: 75f3e8e4 ("firmware: introduce sysfs driver for QEMU's fw_cfg device") Link: https://github.com/ClangBuiltLinux/linux/issues/1299 Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Sami Tolvanen <samitolvanen@google.com> Tested-by:
Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210211194258.4137998-1-nathan@kernel.org Signed-off-by:
-
Dmitry Osipenko authored
commit f6eb84fa upstream. The driver_name="tegra" is now required by the newer ALSA UCMs, otherwise Tegra UCMs don't match by the path/name. All Tegra machine drivers are specifying the card's name, but it has no effect if model name is specified in the device-tree since it overrides the card's name. We need to set the driver_name to "tegra" in order to get a usable lookup path for the updated ALSA UCMs. The new UCM lookup path has a form of driver_name/card_name. The old lookup paths that are based on driver module name continue to work as before. Note that UCM matching never worked for Tegra ASoC drivers if they were compiled as built-in, this is fixed by supporting the new naming scheme. Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210529154649.25936-2-digetx@gmail.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Gao Xiang authored
This is _not_ an upstream commit and just for 5.4.y only. kernel test robot reported a 5.4.y build issue found by randconfig [1] after backporting commit 89b15863 ("lib/lz4: explicitly support in-place decompression"") due to "undefined reference to `memmove'". However, upstream and 5.10 LTS seem fine. After digging further, I found commit a510b616 ("MIPS: Add support for ZSTD-compressed kernels") introduced memmove() occasionally and it has been included since v5.10. This partially cherry-picks the memmove() part of commit a510b616 to fix the reported build regression since we don't need the whole patch for 5.4 LTS at all. [1] https://lore.kernel.org/r/202107070120.6dOj1kB7-lkp@intel.com/ Fixes: defcc2b5 ("lib/lz4: explicitly support in-place decompression") # 5.4.y Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Gao Xiang <hsiangkao@linux.alibaba.com> Signed-off-by:
-
Russ Weight authored
commit d9ec9daa upstream. The stratix10-soc driver uses fpga_mgr_create() function and is therefore responsible to call fpga_mgr_free() to release the class driver resources. Add a missing call to fpga_mgr_free in the s10_remove() function. Signed-off-by:
Russ Weight <russell.h.weight@intel.com> Reviewed-by:
Xu Yilun <yilun.xu@intel.com> Signed-off-by:
Moritz Fischer <mdf@kernel.org> Fixes: e7eef1d7 ("fpga: add intel stratix10 soc fpga manager driver") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210614170909.232415-3-mdf@kernel.org Signed-off-by:
-
Samuel Holland authored
commit 8b33dfe0 upstream. Bad counter reads are experienced sometimes when bit 10 or greater rolls over. Originally, testing showed that at least 10 lower bits would be set to the same value during these bad reads. However, some users still reported time skips. Wider testing revealed that on some chips, occasionally only the lowest 9 bits would read as the anomalous value. During these reads (which still happen only when bit 10), bit 9 would read as the correct value. Reduce the mask by one bit to cover these cases as well. Cc: stable@vger.kernel.org Fixes: c950ca8c ("clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability") Reported-by:
Roman Stratiienko <r.stratiienko@gmail.com> Signed-off-by:
Samuel Holland <samuel@sholland.org> Signed-off-by:
-
Thomas Gleixner authored
commit b22afcdf upstream. Alexey and Joshua tried to solve a cpusets related hotplug problem which is user space visible and results in unexpected behaviour for some time after a CPU has been plugged in and the corresponding uevent was delivered. cpusets delegate the hotplug work (rebuilding cpumasks etc.) to a workqueue. This is done because the cpusets code has already a lock nesting of cgroups_mutex -> cpu_hotplug_lock. A synchronous callback or waiting for the work to finish with cpu_hotplug_lock held can and will deadlock because that results in the reverse lock order. As a consequence the uevent can be delivered before cpusets have consistent state which means that a user space invocation of sched_setaffinity() to move a task to the plugged CPU fails up to the point where the scheduled work has been processed. The same is true for CPU unplug, but that does not create user observable failure (yet). It's still inconsistent to claim that an operation is finished before it actually is and that's the real issue at hand. uevents just make it reliably observable. Obviously the problem should be fixed in cpusets/cgroups, but untangling that is pretty much impossible because according to the changelog of the commit which introduced this 8 years ago: 3a5a6d0c("cpuset: don't nest cgroup_mutex inside get_online_cpus()") the lock order cgroups_mutex -> cpu_hotplug_lock is a design decision and the whole code is built around that. So bite the bullet and invoke the relevant cpuset function, which waits for the work to finish, in _cpu_up/down() after dropping cpu_hotplug_lock and only when tasks are not frozen by suspend/hibernate because that would obviously wait forever. Waiting there with cpu_add_remove_lock, which is protecting the present and possible CPU maps, held is not a problem at all because neither work queues nor cpusets/cgroups have any lockchains related to that lock. Waiting in the hotplug machinery is not problematic either because there are already state callbacks which wait for hardware queues to drain. It makes the operations slightly slower, but hotplug is slow anyway. This ensures that state is consistent before returning from a hotplug up/down operation. It's still inconsistent during the operation, but that's a different story. Add a large comment which explains why this is done and why this is not a dump ground for the hack of the day to work around half thought out locking schemes. Document also the implications vs. hotplug operations and serialization or the lack of it. Thanks to Alexy and Joshua for analyzing why this temporary sched_setaffinity() failure happened. Fixes: 3a5a6d0c("cpuset: don't nest cgroup_mutex inside get_online_cpus()") Reported-by:
Alexey Klimov <aklimov@redhat.com> Reported-by:
Joshua Baker <jobaker@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
-
Timo Sigurdsson authored
commit f6bca4d9 upstream. DIPM is unsupported or broken on sunxi. Trying to enable the power management policy med_power_with_dipm on an Allwinner A20 SoC based board leads to immediate I/O errors and the attached SATA disk disappears from the /dev filesystem. A reset (power cycle) is required to make the SATA controller or disk work again. The A10 and A20 SoC data sheets and manuals don't mention DIPM at all [1], so it's fair to assume that it's simply not supported. But even if it was, it should be considered broken and best be disabled in the ahci_sunxi driver. [1] https://github.com/allwinner-zh/documents/tree/master/ Fixes: c5754b52 ("ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform") Cc: stable@vger.kernel.org Signed-off-by:
Timo Sigurdsson <public_timo.s@silentcreek.de> Tested-by:
-
Christian Löhle authored
commit 09247e11 upstream. While initializing an UHS-I SD card, the mmc core first tries to switch to 1.8V I/O voltage, before it continues to change the settings for the bus speed mode. However, the current behaviour in the mmc core is inconsistent and doesn't conform to the SD spec. More precisely, an SD card that supports UHS-I must set both the SD_OCR_CCS bit and the SD_OCR_S18R bit in the OCR register response. When switching to 1.8V I/O the mmc core correctly checks both of the bits, but only the SD_OCR_S18R bit when changing the settings for bus speed mode. Rather than actually fixing the code to confirm to the SD spec, let's deliberately deviate from it by requiring only the SD_OCR_S18R bit for both parts. This enables us to support UHS-I for SDSC cards (outside spec), which is actually being supported by some existing SDSC cards. Moreover, this fixes the inconsistent behaviour. Signed-off-by:
Christian Loehle <cloehle@hyperstone.com> Link: https://lore.kernel.org/r/CWXP265MB26803AE79E0AD5ED083BF2A6C4529@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM Cc: stable@vger.kernel.org [Ulf: Rewrote commit message and comments to clarify the changes] Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Wolfram Sang authored
commit 77347eda upstream. It might be that something goes wrong during tuning so the MMC core will immediately trigger a retune. In our case it was: - we sent a tuning block - there was an error so we need to send an abort cmd to the eMMC - the abort cmd had a CRC error - retune was set by the MMC core This lead to a vicious circle causing a performance regression of 75%. So, clear retuning flags before we enable retuning to start with a known cleared state. Reported-by Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Suggested-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by:
-
Al Cooper authored
commit d0244847 upstream. When an eMMC device is being run in HS400 mode, any access to the RPMB device will cause the error message "mmc1: Invalid UHS-I mode selected". This happens as a result of tuning being disabled before RPMB access and then re-enabled after the RPMB access is complete. When tuning is re-enabled, the system has to switch from HS400 to HS200 to do the tuning and then back to HS400. As part of sequence to switch from HS400 to HS200 the system is temporarily put into HS mode. When switching to HS mode, sdhci_get_preset_value() is called and does not have support for HS mode and prints the warning message and returns the preset for SDR12. The fix is to add support for MMC and SD HS modes to sdhci_get_preset_value(). This can be reproduced on any system running eMMC in HS400 mode (not HS400ES) by using the "mmc" utility to run the following command: "mmc rpmb read-counter /dev/mmcblk0rpmb". Signed-off-by:
Al Cooper <alcooperx@gmail.com> Acked-by:
-
Daniel Vetter authored
commit 26c3e7fd upstream. Even when all we support is linear, make that explicit. Otherwise the uapi is rather confusing. Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-2-daniel.vetter@ffwll.ch Signed-off-by:
-
Daniel Vetter authored
commit 35cbb8c9 upstream. Setting the cap without the modifier list is very confusing to userspace. Fix that by listing the ones we support explicitly. Stable backport so that userspace can rely on this working in a reasonable way, i.e. that the cap set implies IN_FORMATS is available. Acked-by:
-
Daniel Vetter authored
commit be4306ad upstream. Since commit 890880dd Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. It was slightly inconsistently though, since planes with only linear modifier support haven't listed that explicitly. Fix that, and cc: stable to allow userspace to rely on this. Again don't backport further than where Paul's patch got added. Cc: stable@vger.kernel.org # v5.1 + Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Harry Wentland authored
commit c6c6a712 upstream. [Why] This hasn't been well tested and leads to complete system hangs on DCN1 based systems, possibly others. The system hang can be reproduced by gesturing the video on the YouTube Android app on ChromeOS into full screen. [How] Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. v2: - Add code comment describing the reason we're rejecting non-zero src_x and src_y - Drop gerrit Change-Id - Add stable CC - Based on amd-staging-drm-next v3: removed trailing whitespace Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Cc: stable@vger.kernel.org Cc: nicholas.kazlauskas@amd.com Cc: amd-gfx@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: Roman.Li@amd.com Cc: hersenxs.wu@amd.com Cc: danny.wang@amd.com Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
