summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-11-19HID: multitouch: Fix Iiyama ProLite T1931SAW (0eef:0001 again!)Ondrej Zary
Iiyama ProLite T1931SAW does not work with Linux - input devices are created but cursor does not move. It has the infamous 0eef:0001 ID which has been reused for various devices before. It seems to require export_all_inputs = true. Hopefully there are no HID devices using this ID that will break. It should not break non-HID devices (handled by usbtouchscreen). Signed-off-by: Ondrej Zary <linux@zary.sk> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: nintendo: eliminate dead datastructures in !CONFIG_NINTENDO_FF caseJiri Kosina
The rumbling-related identifiers are never used in !CONFIG_NINTENDO_FF case, so let's hide them in order to avoid unused warnings. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: magicmouse: prevent division by 0 on scrollClaudia Pellegrino
In hid_magicmouse, if the user has set scroll_speed to a value between 55 and 63 and scrolls seven times in quick succession, the step_hr variable in the magicmouse_emit_touch function becomes 0. That causes a division by zero further down in the function when it does `step_x_hr /= step_hr`. To reproduce, create `/etc/modprobe.d/hid_magicmouse.conf` with the following content: ``` options hid_magicmouse scroll_acceleration=1 scroll_speed=55 ``` Then reboot, connect a Magic Mouse and scroll seven times quickly. The system will freeze for a minute, and after that `dmesg` will confirm that a division by zero occurred. Enforce a minimum of 1 for the variable so the high resolution step count can never reach 0 even at maximum scroll acceleration. Fixes: d4b9f10a0eb6 ("HID: magicmouse: enable high-resolution scroll") Signed-off-by: Claudia Pellegrino <linux@cpellegrino.de> Tested-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: thrustmaster: fix sparse warningsVihas Mak
Changed 0 to NULL to fix following sparse warnings: drivers/hid/hid-thrustmaster.c:208:43: warning: Using plain integer as NULL pointer drivers/hid/hid-thrustmaster.c:241:17: warning: Using plain integer as NULL pointer drivers/hid/hid-thrustmaster.c:275:37: warning: Using plain integer as NULL pointer Signed-off-by: Vihas Mak <makvihas@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: Ignore battery for Elan touchscreen on HP Envy X360 15-eu0xxxTrevor Davenport
Battery status is reported for the HP Envy X360 Convertible 15-eu0xxx even if it does not have a battery. Prevent it from always reporting the battery as low. Signed-off-by: Trevor Davenport <trevor.davenport@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: input: set usage type to key on keycode remapThomas Weißschuh
When a scancode is manually remapped that previously was not handled as key, then the old usage type was incorrectly reused. This caused issues on a "04b3:301b IBM Corp. SK-8815 Keyboard" which has marked some of its keys with an invalid HID usage. These invalid usage keys are being ignored since support for USB programmable buttons was added. The scancodes are however remapped explicitly by the systemd hwdb to the keycodes that are printed on the physical buttons. During this mapping step the existing usage is retrieved which will be found with a default type of 0 (EV_SYN) instead of EV_KEY. The events with the correct code but EV_SYN type are not forwarded to userspace. This also leads to a kernel oops when trying to print the report descriptor via debugfs. hid_resolv_event() tries to resolve a EV_SYN event with an EV_KEY code which leads to an out-of-bounds access in the EV_SYN names array. Fixes: bcfa8d1457 ("HID: input: Add support for Programmable Buttons") Fixes: f5854fad39 ("Input: hid-input - allow mapping unknown usages") Reported-by: Brent Roman <brent@mbari.org> Tested-by: Brent Roman <brent@mbari.org> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: input: Fix parsing of HID_CP_CONSUMER_CONTROL fieldsHans de Goede
Fix parsing of HID_CP_CONSUMER_CONTROL fields which are not in the HID_CP_PROGRAMMABLEBUTTONS collection. Fixes: bcfa8d14570d ("HID: input: Add support for Programmable Buttons") BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2018096 Cc: Thomas Weißschuh <linux@weissschuh.net> Suggested-by: Benjamin Tissoires <btissoir@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-By: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: ft260: fix i2c probing for hwmon devicesMichael Zaidman
The below scenario causes the kernel NULL pointer dereference failure: 1. sudo insmod hid-ft260.ko 2. sudo modprobe lm75 3. unplug USB hid-ft260 4. plug USB hid-ft260 [ +0.000006] Call Trace: [ +0.000004] __i2c_smbus_xfer.part.0+0xd1/0x310 [ +0.000007] ? ft260_smbus_write+0x140/0x140 [hid_ft260] [ +0.000005] __i2c_smbus_xfer+0x2b/0x80 [ +0.000004] i2c_smbus_xfer+0x61/0xf0 [ +0.000005] i2c_default_probe+0xf9/0x130 [ +0.000004] i2c_detect_address+0x84/0x160 [ +0.000004] ? kmem_cache_alloc_trace+0xf6/0x200 [ +0.000009] ? i2c_detect.isra.0+0x69/0x130 [ +0.000005] i2c_detect.isra.0+0xbf/0x130 [ +0.000004] ? __process_new_driver+0x30/0x30 [ +0.000004] __process_new_adapter+0x18/0x20 [ +0.000004] bus_for_each_drv+0x84/0xd0 [ +0.000003] i2c_register_adapter+0x1e4/0x400 [ +0.000005] i2c_add_adapter+0x5c/0x80 [ +0.000004] ft260_probe.cold+0x222/0x2e2 [hid_ft260] [ +0.000006] hid_device_probe+0x10e/0x170 [hid] [ +0.000009] really_probe+0xff/0x460 [ +0.000004] driver_probe_device+0xe9/0x160 [ +0.000003] __device_attach_driver+0x71/0xd0 [ +0.000004] ? driver_allows_async_probing+0x50/0x50 [ +0.000004] bus_for_each_drv+0x84/0xd0 [ +0.000002] __device_attach+0xde/0x1e0 [ +0.000004] device_initial_probe+0x13/0x20 [ +0.000004] bus_probe_device+0x8f/0xa0 [ +0.000003] device_add+0x333/0x5f0 It happened when i2c core probed for the devices associated with the lm75 driver by invoking 2c_detect()-->..-->ft260_smbus_write() from within the ft260_probe before setting the adapter data with i2c_set_adapdata(). Moving the i2c_set_adapdata() before i2c_add_adapter() fixed the failure. Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com> Signed-off-by: Germain Hebert <germain.hebert@ca.abb.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19MAINTAINERS: Update for VMware PVRDMA driverBryan Tan
Update maintainer info for the VMware PVRDMA driver. Link: https://lore.kernel.org/r/1637320770-44878-1-git-send-email-bryantan@vmware.com Reviewed-by: Adit Ranadive <aditr@vmware.com> Reviewed-by: Vishnu Dasa <vdasa@vmware.com> Signed-off-by: Bryan Tan <bryantan@vmware.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-19blk-mq: don't insert FUA request with data into scheduler queueMing Lei
We never insert flush request into scheduler queue before. Recently commit d92ca9d8348f ("blk-mq: don't handle non-flush requests in blk_insert_flush") tries to handle FUA data request as normal request. This way has caused warning[1] in mq-deadline dd_exit_sched() or io hang in case of kyber since RQF_ELVPRIV isn't set for flush request, then ->finish_request won't be called. Fix the issue by inserting FUA data request with blk_mq_request_bypass_insert() when the device supports FUA, just like what we did before. [1] https://lore.kernel.org/linux-block/CAHj4cs-_vkTW=dAzbZYGxpEWSpzpcmaNeY1R=vH311+9vMUSdg@mail.gmail.com/ Reported-by: Yi Zhang <yi.zhang@redhat.com> Fixes: d92ca9d8348f ("blk-mq: don't handle non-flush requests in blk_insert_flush") Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20211118153041.2163228-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-11-19blk-cgroup: fix missing put device in error path from blkg_conf_pref()Yu Kuai
If blk_queue_enter() failed due to queue is dying, the blkdev_put_no_open() is needed because blkcg_conf_open_bdev() succeeded. Fixes: 0c9d338c8443 ("blk-cgroup: synchronize blkg creation against policy deactivation") Signed-off-by: Yu Kuai <yukuai3@huawei.com> Acked-by: Tejun Heo <tj@kernel.org> Link: https://lore.kernel.org/r/20211102020705.2321858-1-yukuai3@huawei.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-11-19stmmac_pci: Fix underflow size in stmmac_rxZekun Shen
This bug report came up when we were testing the device driver by fuzzing. It shows that buf1_len can get underflowed and be 0xfffffffc (4294967292). This bug is triggerable with a compromised/malfunctioning device. We found the bug through QEMU emulation tested the patch with emulation. We did NOT test it on real hardware. Attached is the bug report by fuzzing. BUG: KASAN: use-after-free in stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac] Read of size 4294967292 at addr ffff888016358000 by task ksoftirqd/0/9 CPU: 0 PID: 9 Comm: ksoftirqd/0 Tainted: G W 5.6.0 #1 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac] ? stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac] __kasan_report.cold+0x37/0x7c ? stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac] kasan_report+0xe/0x20 check_memory_region+0x15a/0x1d0 memcpy+0x20/0x50 stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac] ? stmmac_suspend+0x850/0x850 [stmmac] ? __next_timer_interrupt+0xba/0xf0 net_rx_action+0x363/0xbd0 ? call_timer_fn+0x240/0x240 ? __switch_to_asm+0x40/0x70 ? napi_busy_loop+0x520/0x520 ? __schedule+0x839/0x15a0 __do_softirq+0x18c/0x634 ? takeover_tasklets+0x5f0/0x5f0 run_ksoftirqd+0x15/0x20 smpboot_thread_fn+0x2f1/0x6b0 ? smpboot_unregister_percpu_thread+0x160/0x160 ? __kthread_parkme+0x80/0x100 ? smpboot_unregister_percpu_thread+0x160/0x160 kthread+0x2b5/0x3b0 ? kthread_create_on_node+0xd0/0xd0 ret_from_fork+0x22/0x40 Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu> Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19atlantic: fix double-free in aq_ring_tx_cleanZekun Shen
We found this bug while fuzzing the device driver. Using and freeing the dangling pointer buff->skb would cause use-after-free and double-free. This bug is triggerable with compromised/malfunctioning devices. We found the bug with QEMU emulation and tested the patch by emulation. We did NOT test on a real device. Attached is the bug report. BUG: KASAN: double-free or invalid-free in consume_skb+0x6c/0x1c0 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? consume_skb+0x6c/0x1c0 kasan_report_invalid_free+0x61/0xa0 ? consume_skb+0x6c/0x1c0 __kasan_slab_free+0x15e/0x170 ? consume_skb+0x6c/0x1c0 kfree+0x8c/0x230 consume_skb+0x6c/0x1c0 aq_ring_tx_clean+0x5c2/0xa80 [atlantic] aq_vec_poll+0x309/0x5d0 [atlantic] ? _sub_I_65535_1+0x20/0x20 [atlantic] ? __next_timer_interrupt+0xba/0xf0 net_rx_action+0x363/0xbd0 ? call_timer_fn+0x240/0x240 ? __switch_to_asm+0x34/0x70 ? napi_busy_loop+0x520/0x520 ? net_tx_action+0x379/0x720 __do_softirq+0x18c/0x634 ? takeover_tasklets+0x5f0/0x5f0 run_ksoftirqd+0x15/0x20 smpboot_thread_fn+0x2f1/0x6b0 ? smpboot_unregister_percpu_thread+0x160/0x160 ? __kthread_parkme+0x80/0x100 ? smpboot_unregister_percpu_thread+0x160/0x160 kthread+0x2b5/0x3b0 ? kthread_create_on_node+0xd0/0xd0 ret_from_fork+0x22/0x40 Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu> Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Reviewed-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19net: marvell: prestera: fix double free issue on err pathVolodymyr Mytnyk
fix error path handling in prestera_bridge_port_join() that cases prestera driver to crash (see below). Trace: Internal error: Oops: 96000044 [#1] SMP Modules linked in: prestera_pci prestera uio_pdrv_genirq CPU: 1 PID: 881 Comm: ip Not tainted 5.15.0 #1 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : prestera_bridge_destroy+0x2c/0xb0 [prestera] lr : prestera_bridge_port_join+0x2cc/0x350 [prestera] sp : ffff800011a1b0f0 ... x2 : ffff000109ca6c80 x1 : dead000000000100 x0 : dead000000000122 Call trace: prestera_bridge_destroy+0x2c/0xb0 [prestera] prestera_bridge_port_join+0x2cc/0x350 [prestera] prestera_netdev_port_event.constprop.0+0x3c4/0x450 [prestera] prestera_netdev_event_handler+0xf4/0x110 [prestera] raw_notifier_call_chain+0x54/0x80 call_netdevice_notifiers_info+0x54/0xa0 __netdev_upper_dev_link+0x19c/0x380 Fixes: e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver implementation") Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19net: marvell: prestera: fix brige port operationVolodymyr Mytnyk
Return NOTIFY_DONE (dont't care) for switchdev notifications that prestera driver don't know how to handle them. With introduction of SWITCHDEV_BRPORT_[UN]OFFLOADED switchdev events, the driver rejects adding swport to bridge operation which is handled by prestera_bridge_port_join() func. The root cause of this is that prestera driver returns error (EOPNOTSUPP) in prestera_switchdev_blk_event() handler for unknown swdev events. This causes switchdev_bridge_port_offload() to fail when adding port to bridge in prestera_bridge_port_join(). Fixes: 957e2235e526 ("net: make switchdev_bridge_port_{,unoffload} loosely coupled with the bridge") Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19drm/aspeed: Fix vga_pw sysfs outputJoel Stanley
Before the drm driver had support for this file there was a driver that exposed the contents of the vga password register to userspace. It would present the entire register instead of interpreting it. The drm implementation chose to mask of the lower bit, without explaining why. This breaks the existing userspace, which is looking for 0xa8 in the lower byte. Change our implementation to expose the entire register. Fixes: 696029eb36c0 ("drm/aspeed: Add sysfs for output settings") Reported-by: Oskar Senft <osk@google.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> Tested-by: Oskar Senft <osk@google.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211117010145.297253-1-joel@jms.id.au
2021-11-19Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter/IPVS fixes for net: 1) Add selftest for vrf+conntrack, from Florian Westphal. 2) Extend nfqueue selftest to cover nfqueue, also from Florian. 3) Remove duplicated include in nft_payload, from Wan Jiabing. 4) Several improvements to the nat port shadowing selftest, from Phil Sutter. 5) Fix filtering of reply tuple in ctnetlink, from Florent Fourcot. 6) Do not override error with -EINVAL in filter setup path, also from Florent. 7) Honor sysctl_expire_nodest_conn regardless conn_reuse_mode for reused connections, from yangxingwu. 8) Replace snprintf() by sysfs_emit() in xt_IDLETIMER as reported by Coccinelle, from Jing Yao. 9) Incorrect IPv6 tunnel match in flowtable offload, from Will Mortensen. 10) Switch port shadow selftest to use socat, from Florian Westphal. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-19drm/vc4: fix error code in vc4_create_object()Dan Carpenter
The ->gem_create_object() functions are supposed to return NULL if there is an error. None of the callers expect error pointers so returing one will lead to an Oops. See drm_gem_vram_create(), for example. Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211118111416.GC1147@kili
2021-11-19ALSA: usb-audio: Don't start stream for capture at prepareTakashi Iwai
The recent change made mistakenly the stream for capture started at prepare stage. Add the stream direction check to avoid it. Fixes: 9c9a3b9da891 ("ALSA: usb-audio: Rename early_playback_start flag with lowlatency_playback") Link: https://lore.kernel.org/r/20211119102629.7476-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-19ALSA: usb-audio: Switch back to non-latency mode at a later pointTakashi Iwai
The recent regression report revealed that the judgment of the low-latency playback mode based on the runtime->stop_threshold cannot work reliably at the prepare stage, as sw_params call may happen at any time, and PCM dmix actually sets it up after the prepare call. This ended up with the stall of the stream as PCM ack won't be issued at all. For addressing this, check the free-wheeling mode again at the PCM trigger right before starting the stream again, and allow switching to the non-LL mode at a late stage. Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support") Reported-and-tested-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Link: https://lore.kernel.org/r/20211117161855.m45mxcqszkfcetai@box.shutemov.name Link: https://lore.kernel.org/r/20211119102459.7055-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-18riscv: fix building external modulesAndreas Schwab
When building external modules, vdso_prepare should not be run. If the kernel sources are read-only, it will fail. Fixes: fde9c59aebaf ("riscv: explicitly use symbol offsets for VDSO") Signed-off-by: Andreas Schwab <schwab@suse.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2021-11-18RISC-V: Enable KVM in RV64 and RV32 defconfigs as a moduleAnup Patel
Let's enable KVM RISC-V in RV64 and RV32 defconfigs as module so that it always built along with the default kernel image. Signed-off-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2021-11-19media: hi846: remove the of_match_ptr macroMartin Kepplinger
Similar to other drivers, this should fix a Clang compilar warning when building without CONFIG_OF in which case of_match_ptr() is NULL and the const struct we would use otherwise is unused. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-19media: hi846: include property.h instead of of_graph.hMartin Kepplinger
Include the more portable property.h instead of the OF specific of_graph.h Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-11-19Merge tag 'amd-drm-fixes-5.16-2021-11-17' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-5.16-2021-11-17: amdgpu: - Better debugging info for SMU msgs - Better error reporting when adding IP blocks - Fix UVD powergating regression on CZ - Clock reporting fix for navi1x - OLED panel backlight fix - Fix scaling on VGA/DVI for non-DC display code - Fix GLFCLK handling for RGP on some APUs - fix potential memory leak amdkfd: - GPU reset fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211118041638.20831-1-alexander.deucher@amd.com
2021-11-18scsi: target: configfs: Delete unnecessary checks for NULLDan Carpenter
The "item" pointer is always going to be valid pointer and does not need to be checked. But if "item" were NULL then item_to_lun() would not return a NULL, but instead, the container_of() pointer math would return a value in the error pointer range. This confuses static checkers since it looks like a NULL vs IS_ERR() bug. Delete the bogus checks. Link: https://lore.kernel.org/r/20211118084900.GA24550@kili Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-11-18scsi: target: core: Use RCU helpers for INQUIRY t10_alua_tg_pt_gpMike Christie
Fix the sparse warnings about t10_alua_tg_pt_gp accesses in target_core_spc.c caused by commit 7324f47d4293 ("scsi: target: Replace lun_tg_pt_gp_lock with rcu in I/O path") That commit replaced the lun_tg_pt_gp_lock use in the I/O path, but it didn't update the INQUIRY code. Link: https://lore.kernel.org/r/20211117213928.8634-1-michael.christie@oracle.com Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-11-18scsi: mpt3sas: Fix incorrect system timestampSreekanth Reddy
For updating the IOC firmware's timestamp with system timestamp, the driver issues the Mpi26IoUnitControlRequest message. While framing the Mpi26IoUnitControlRequest, the driver should copy the lower 32 bits of the current timestamp into IOCParameterValue field and the higher 32 bits into Reserved7 field. Link: https://lore.kernel.org/r/20211117123215.25487-1-sreekanth.reddy@broadcom.com Fixes: f98790c00375 ("scsi: mpt3sas: Sync time periodically between driver and firmware") Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-11-18scsi: mpt3sas: Fix system going into read-only modeSreekanth Reddy
While determining the SAS address of a drive, the driver checks whether the handle number is less than the HBA phy count or not. If the handle number is less than the HBA phy count then driver assumes that this handle belongs to HBA and hence it assigns the HBA SAS address. During IOC firmware downgrade operation, if the number of HBA phys is reduced and the OS drive's device handle drops below the phy count while determining the drive's SAS address, the driver ends up using the HBA's SAS address. This leads to a mismatch of drive's SAS address and hence the driver unregisters the OS drive and the system goes into read-only mode. Update the IOC's num_phys to the HBA phy count provided by actual loaded firmware. Link: https://lore.kernel.org/r/20211117105058.3505-1-sreekanth.reddy@broadcom.com Fixes: a5e99fda0172 ("scsi: mpt3sas: Update hba_port objects after host reset") Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-11-19Merge tag 'drm-intel-fixes-2021-11-18' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes One quick fix for return error handling, one fix for ADL-P display and one revert targeting stable 5.4, for TGL's DSI display clocks Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YZbUPIHpR1S3JZ2b@intel.com
2021-11-19Merge tag 'drm-misc-fixes-2021-11-18' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes A infoframe corruption fix for nouveau, a wrong free function usage fix for GEM CMA helpers, a Kconfig dependency fix for sun4i, two fixes for drm/scheduler refcounting and a probing fix for efifb. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211118075447.5rn6zaulnrequqnm@gilmour
2021-11-18scsi: mpt3sas: Fix kernel panic during drive powercycle testSreekanth Reddy
While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact. Consequently, a kernel panic can occur while the driver is trying to access the sas_address field of sas_target object without also checking the sas_target object for NULL. Link: https://lore.kernel.org/r/20211117104909.2069-1-sreekanth.reddy@broadcom.com Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS") Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-11-18scsi: ufs: ufs-mediatek: Add put_device() after of_find_device_by_node()Ye Guojin
This was found by coccicheck: ./drivers/scsi/ufs/ufs-mediatek.c, 211, 1-7, ERROR missing put_device; call of_find_device_by_node on line 1185, but without a corresponding object release within this function. Link: https://lore.kernel.org/r/20211110105133.150171-1-ye.guojin@zte.com.cn Reported-by: Zeal Robot <zealci@zte.com.cn> Reviewed-by: Peter Wang <peter.wang@mediatek.com> Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-11-18scsi: scsi_debug: Fix type in min_t to avoid stack OOBGeorge Kennedy
Change min_t() to use type "u32" instead of type "int" to avoid stack out of bounds. With min_t() type "int" the values get sign extended and the larger value gets used causing stack out of bounds. BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 Read of size 127 at addr ffff888072607128 by task syz-executor.7/18707 CPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189 memcpy+0x23/0x60 mm/kasan/shadow.c:65 memcpy include/linux/fortify-string.h:191 [inline] sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000 fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162 fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline] resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887 schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533 scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline] scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836 sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774 sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Link: https://lore.kernel.org/r/1636484247-21254-1-git-send-email-george.kennedy@oracle.com Reported-by: syzkaller <syzkaller@googlegroups.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: George Kennedy <george.kennedy@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-11-18scsi: qla2xxx: edif: Fix off by one bug in qla_edif_app_getfcinfo()Dan Carpenter
The > comparison needs to be >= to prevent accessing one element beyond the end of the app_reply->ports[] array. Link: https://lore.kernel.org/r/20211109115219.GE16587@kili Fixes: 7878f22a2e03 ("scsi: qla2xxx: edif: Add getfcinfo and statistic bsgs") Reviewed-by: Ewan D. Milne <emilne@redhat.com> Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-11-18scsi: ufs: ufshpb: Fix warning in ufshpb_set_hpb_read_to_upiu()Bean Huo
Fix the following sparse warnings in ufshpb_set_hpb_read_to_upiu(): sparse warnings: (new ones prefixed by >>) drivers/scsi/ufs/ufshpb.c:335:27: sparse: sparse: cast from restricted __be64 drivers/scsi/ufs/ufshpb.c:335:25: sparse: expected restricted __be64 [usertype] ppn_tmp drivers/scsi/ufs/ufshpb.c:335:25: sparse: got unsigned long long [usertype] Link: https://lore.kernel.org/r/20211111222452.384089-1-huobean@gmail.com Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Bean Huo <beanhuo@micron.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-11-18tracing: Don't use out-of-sync va_list in event printingNikita Yushchenko
If trace_seq becomes full, trace_seq_vprintf() no longer consumes arguments from va_list, making va_list out of sync with format processing by trace_check_vprintf(). This causes va_arg() in trace_check_vprintf() to return wrong positional argument, which results into a WARN_ON_ONCE() hit. ftrace_stress_test from LTP triggers this situation. Fix it by explicitly avoiding further use if va_list at the point when it's consistency can no longer be guaranteed. Link: https://lkml.kernel.org/r/20211118145516.13219-1-nikita.yushchenko@virtuozzo.com Signed-off-by: Nikita Yushchenko <nikita.yushchenko@virtuozzo.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2021-11-18tracing: Use memset_startat() to zero struct trace_iteratorKees Cook
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memset(), avoid intentionally writing across neighboring fields. Use memset_startat() to avoid confusing memset() about writing beyond the target struct member. Link: https://lkml.kernel.org/r/20211118202217.1285588-1-keescook@chromium.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2021-11-18Merge tag 'zstd-for-linus-5.16-rc1' of git://github.com/terrelln/linuxLinus Torvalds
Pull zstd fixes from Nick Terrell: "Fix stack usage on parisc & improve code size bloat This contains three commits: 1. Fixes a minor unused variable warning reported by Kernel test robot [0]. 2. Improves the reported code bloat (-88KB / 374KB) [1] by outlining some functions that are unlikely to be used in performance sensitive workloads. 3. Fixes the reported excess stack usage on parisc [2] by removing -O3 from zstd's compilation flags. -O3 triggered bugs in the hppa-linux-gnu gcc-8 compiler. -O2 performance is acceptable: neutral compression, about -1% decompression speed. We also reduce code bloat (-105KB / 374KB). After this our code bloat is cut from 374KB to 105KB with gcc-11. If we wanted to cut the remaining 105KB we'd likely have to trade signicant performance, so I want to say that this is enough for now. We should be able to get further gains without sacrificing speed, but that will take some significant optimization effort, and isn't suitable for a quick fix. I've opened an upstream issue [3] to track the code size, and try to avoid future regressions, and improve it in the long term" Link: https://lore.kernel.org/linux-mm/202111120312.833wII4i-lkp@intel.com/T/ [0] Link: https://lkml.org/lkml/2021/11/15/710 [1] Link: https://lkml.org/lkml/2021/11/14/189 [2] Link: https://github.com/facebook/zstd/issues/2867 [3] Link: https://lore.kernel.org/r/20211117014949.1169186-1-nickrterrell@gmail.com/ Link: https://lore.kernel.org/r/20211117201459.1194876-1-nickrterrell@gmail.com/ * tag 'zstd-for-linus-5.16-rc1' of git://github.com/terrelln/linux: lib: zstd: Don't add -O3 to cflags lib: zstd: Don't inline functions in zstd_opt.c lib: zstd: Fix unused variable warning
2021-11-18drm/nouveau/acr: fix a couple NULL vs IS_ERR() checksDan Carpenter
The nvkm_acr_lsfw_add() function never returns NULL. It returns error pointers on error. Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure boot"") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211118111314.GB1147@kili
2021-11-18drm/nouveau: recognise GA106Ben Skeggs
I've got HW now, appears to work as expected so far. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: <stable@vger.kernel.org> # 5.14+ Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211118030413.2610-1-skeggsb@gmail.com
2021-11-18Merge tag 'thermal-5.16-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fixes from Rafael Wysocki: "These fix the handling of thermal zones during system resume and disable building of the int340x thermal driver on 32-bit. Specifics: - Prevent the previous high and low thermal zone trip values from being retained over a system suspend-resume cycle (Manaf Meethalavalappu Pallikunhi) - Prevent the int340x thermal driver from being built in 32-bit kernel configurations, because running it on 32-bit is questionable (Arnd Bergmann)" * tag 'thermal-5.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: core: Reset previous low and high trip during thermal zone init thermal: int340x: Limit Kconfig to 64-bit
2021-11-18Merge tag 'pm-5.16-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix a system-wide suspend issue in the DTPM framework and improve the Energy Model documentation. Specifics: - Fix system suspend handling in DTPM when it is enabled, but not actually used (Daniel Lezcano) - Describe the new cpufreq callback for Energy Model registration and explain the "advanced" and "simple" EM variants in the EM documentation (Lukasz Luba)" * tag 'pm-5.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Documentation: power: Describe 'advanced' and 'simple' EM models Documentation: power: Add description about new callback for EM registration powercap: DTPM: Fix suspend failure and kernel warning
2021-11-18Merge tag 'acpi-5.16-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "Revert the change attempting to release PM resources blocked by unused ACPI objects after device enumeration, because it caused boot issues to appear on multiple systems" * tag 'acpi-5.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "ACPI: scan: Release PM resources blocked by unused objects"
2021-11-18Merge tag 'platform-drivers-x86-v5.16-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Hans de Goede: "Various build- and bug-fixes as well as one hardware-id addition" * tag 'platform-drivers-x86-v5.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: thinkpad_acpi: fix documentation for adaptive keyboard platform/x86: thinkpad_acpi: Fix WWAN device disabled issue after S3 deep platform/x86: thinkpad_acpi: Add support for dual fan control platform/x86: think-lmi: Abort probe on analyze failure platform/x86: dell-wmi-descriptor: disable by default platform/x86: samsung-laptop: Fix typo in a comment platform/x86: hp_accel: Fix an error handling path in 'lis3lv02d_probe()' platform/x86: amd-pmc: Make CONFIG_AMD_PMC depend on RTC_CLASS platform/mellanox: mlxreg-lc: fix error code in mlxreg_lc_create_static_devices()
2021-11-18Merge tag 'spi-fix-v5.16-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A few small fixes for v5.16, one in the core for an issue with handling of controller unregistration that was introduced with the fixes for registering nested SPI controllers and a few more minor device specific ones" * tag 'spi-fix-v5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: fix use-after-free of the add_lock mutex spi: spi-geni-qcom: fix error handling in spi_geni_grab_gpi_chan() spi: lpspi: Silence error message upon deferred probe spi: cadence-quadspi: fix write completion support
2021-11-18ARM: socfpga: Fix crash with CONFIG_FORTIRY_SOURCETakashi Iwai
When CONFIG_FORTIFY_SOURCE is set, memcpy() checks the potential buffer overflow and panics. The code in sofcpga bootstrapping contains the memcpy() calls are mistakenly translated as the shorter size, hence it triggers a panic as if it were overflowing. This patch changes the secondary_trampoline and *_end definitions to arrays for avoiding the false-positive crash above. Fixes: 9c4566a117a6 ("ARM: socfpga: Enable SMP for socfpga") Suggested-by: Kees Cook <keescook@chromium.org> Buglink: https://bugzilla.suse.com/show_bug.cgi?id=1192473 Link: https://lore.kernel.org/r/20211117193244.31162-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-11-18ALSA: ctxfi: Fix out-of-range accessTakashi Iwai
The master and next_conj of rcs_ops are used for iterating the resource list entries, and currently those are supposed to return the current value. The problem is that next_conf may go over the last entry before the loop abort condition is evaluated, and it may return the "current" value that is beyond the array size. It was caught recently as a GPF, for example. Those return values are, however, never actually evaluated, hence basically we don't have to consider the current value as the return at all. By dropping those return values, the potential out-of-range access above is also fixed automatically. This patch changes the return type of master and next_conj callbacks to void and drop the superfluous code accordingly. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214985 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211118215729.26257-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-18lib: zstd: Don't add -O3 to cflagsNick Terrell
After the update to zstd-1.4.10 passing -O3 is no longer necessary to get good performance from zstd. Using the default optimization level -O2 is sufficient to get good performance. I've measured no significant change to compression speed, and a ~1% decompression speed loss, which is acceptable. This fixes the reported parisc -Wframe-larger-than=1536 errors [0]. The gcc-8-hppa-linux-gnu compiler performed very poorly with -O3, generating stacks that are ~3KB. With -O2 these same functions generate stacks in the < 100B, completely fixing the problem. Function size deltas are listed below: ZSTD_compressBlock_fast_extDict_generic: 3800 -> 68 ZSTD_compressBlock_fast: 2216 -> 40 ZSTD_compressBlock_fast_dictMatchState: 1848 -> 64 ZSTD_compressBlock_doubleFast_extDict_generic: 3744 -> 76 ZSTD_fillDoubleHashTable: 3252 -> 0 ZSTD_compressBlock_doubleFast: 5856 -> 36 ZSTD_compressBlock_doubleFast_dictMatchState: 5380 -> 84 ZSTD_copmressBlock_lazy2: 2420 -> 72 Additionally, this improves the reported code bloat [1]. With gcc-11 bloat-o-meter shows an 80KB code size improvement: ``` > ../scripts/bloat-o-meter vmlinux.old vmlinux add/remove: 31/8 grow/shrink: 24/155 up/down: 25734/-107924 (-82190) Total: Before=6418562, After=6336372, chg -1.28% ``` Compared to before the zstd-1.4.10 update we see a total code size regression of 105KB, down from 374KB at v5.16-rc1: ``` > ../scripts/bloat-o-meter vmlinux.old vmlinux add/remove: 292/62 grow/shrink: 56/88 up/down: 235009/-127487 (107522) Total: Before=6228850, After=6336372, chg +1.73% ``` [0] https://lkml.org/lkml/2021/11/15/710 [1] https://lkml.org/lkml/2021/11/14/189 Link: https://lore.kernel.org/r/20211117014949.1169186-4-nickrterrell@gmail.com/ Link: https://lore.kernel.org/r/20211117201459.1194876-4-nickrterrell@gmail.com/ Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Nick Terrell <terrelln@fb.com>
2021-11-18lib: zstd: Don't inline functions in zstd_opt.cNick Terrell
`zstd_opt.c` contains the match finder for the highest compression levels. These levels are already very slow, and are unlikely to be used in the kernel. If they are used, they shouldn't be used in latency sensitive workloads, so slowing them down shouldn't be a big deal. This saves 188 KB of the 288 KB regression reported by Geert Uytterhoeven [0]. I've also opened an issue upstream [1] so that we can properly tackle the code size issue in `zstd_opt.c` for all users, and can hopefully remove this hack in the next zstd version we import. Bloat-o-meter output on x86-64: ``` > ../scripts/bloat-o-meter vmlinux.old vmlinux add/remove: 6/5 grow/shrink: 1/9 up/down: 16673/-209939 (-193266) Function old new delta ZSTD_compressBlock_opt_generic.constprop - 7559 +7559 ZSTD_insertBtAndGetAllMatches - 6304 +6304 ZSTD_insertBt1 - 1731 +1731 ZSTD_storeSeq - 693 +693 ZSTD_BtGetAllMatches - 255 +255 ZSTD_updateRep - 128 +128 ZSTD_updateTree 96 99 +3 ZSTD_insertAndFindFirstIndexHash3 81 - -81 ZSTD_setBasePrices.constprop 98 - -98 ZSTD_litLengthPrice.constprop 138 - -138 ZSTD_count 362 181 -181 ZSTD_count_2segments 1407 938 -469 ZSTD_insertBt1.constprop 2689 - -2689 ZSTD_compressBlock_btultra2 19990 423 -19567 ZSTD_compressBlock_btultra 19633 15 -19618 ZSTD_initStats_ultra 19825 - -19825 ZSTD_compressBlock_btopt 20374 12 -20362 ZSTD_compressBlock_btopt_extDict 29984 12 -29972 ZSTD_compressBlock_btultra_extDict 30718 15 -30703 ZSTD_compressBlock_btopt_dictMatchState 32689 12 -32677 ZSTD_compressBlock_btultra_dictMatchState 33574 15 -33559 Total: Before=6611828, After=6418562, chg -2.92% ``` [0] https://lkml.org/lkml/2021/11/14/189 [1] https://github.com/facebook/zstd/issues/2862 Link: https://lore.kernel.org/r/20211117014949.1169186-3-nickrterrell@gmail.com/ Link: https://lore.kernel.org/r/20211117201459.1194876-3-nickrterrell@gmail.com/ Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Nick Terrell <terrelln@fb.com>
generated by cgit (git 2.34.1) at 2025-09-13 21:06:14 +0000