summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2022-08-25HID: hidraw: fix memory leak in hidraw_release()Karthik Alapati
Free the buffered reports before deleting the list entry. BUG: memory leak unreferenced object 0xffff88810e72f180 (size 32): comm "softirq", pid 0, jiffies 4294945143 (age 16.080s) hex dump (first 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814ac6c3>] kmemdup+0x23/0x50 mm/util.c:128 [<ffffffff8357c1d2>] kmemdup include/linux/fortify-string.h:440 [inline] [<ffffffff8357c1d2>] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521 [<ffffffff8356ddad>] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992 [<ffffffff8356e41e>] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065 [<ffffffff835f0d3f>] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284 [<ffffffff82d3c7f9>] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670 [<ffffffff82d3cc26>] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747 [<ffffffff82ef1e14>] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988 [<ffffffff812f50a8>] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474 [<ffffffff812f5586>] expire_timers kernel/time/timer.c:1519 [inline] [<ffffffff812f5586>] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790 [<ffffffff812f56e4>] __run_timers kernel/time/timer.c:1768 [inline] [<ffffffff812f56e4>] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803 [<ffffffff848000e6>] __do_softirq+0xe6/0x2ea kernel/softirq.c:571 [<ffffffff81246db0>] invoke_softirq kernel/softirq.c:445 [inline] [<ffffffff81246db0>] __irq_exit_rcu kernel/softirq.c:650 [inline] [<ffffffff81246db0>] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662 [<ffffffff84574f02>] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106 [<ffffffff84600c8b>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649 [<ffffffff8458a070>] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline] [<ffffffff8458a070>] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline] [<ffffffff8458a070>] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline] [<ffffffff8458a070>] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554 Link: https://syzkaller.appspot.com/bug?id=19a04b43c75ed1092021010419b5e560a8172c4f Reported-by: syzbot+f59100a0428e6ded9443@syzkaller.appspotmail.com Signed-off-by: Karthik Alapati <mail@karthek.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-08-25HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_reportLee Jones
It is possible for a malicious device to forgo submitting a Feature Report. The HID Steam driver presently makes no prevision for this and de-references the 'struct hid_report' pointer obtained from the HID devices without first checking its validity. Let's change that. Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Fixes: c164d6abf3841 ("HID: add driver for Valve Steam Controller") Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-08-24fbdev: Move fbdev drivers from strlcpy to strscpyWolfram Sang
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Helge Deller <deller@gmx.de>
2022-08-24fbdev: omap: Remove unnecessary print function dev_err()Jiapeng Chong
The print function dev_err() is redundant because platform_get_irq() already prints an error. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1957 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Helge Deller <deller@gmx.de>
2022-08-24fbdev: chipsfb: Add missing pci_disable_device() in chipsfb_pci_init()Yang Yingliang
Add missing pci_disable_device() in error path in chipsfb_pci_init(). Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Helge Deller <deller@gmx.de>
2022-08-24fbdev: fbcon: Destroy mutex on freeing struct fb_infoShigeru Yoshida
It's needed to destroy bl_curve_mutex on freeing struct fb_info since the mutex is embedded in the structure and initialized when it's allocated. Signed-off-by: Shigeru Yoshida <syoshida@redhat.com> Signed-off-by: Helge Deller <deller@gmx.de>
2022-08-24fbdev: radeon: Clean up some inconsistent indentingJiapeng Chong
No functional modification involved. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1932 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Helge Deller <deller@gmx.de>
2022-08-24fbdev: sisfb: Clean up some inconsistent indentingJiapeng Chong
No functional modification involved. drivers/video/fbdev/sis/sis_main.c:6165 sisfb_probe() warn: inconsistent indenting. drivers/video/fbdev/sis/sis_main.c:4266 sisfb_post_300_rwtest() warn: inconsistent indenting. drivers/video/fbdev/sis/sis_main.c:2388 SISDoSense() warn: inconsistent indenting. drivers/video/fbdev/sis/sis_main.c:2531 SiS_Sense30x() warn: inconsistent indenting. drivers/video/fbdev/sis/sis_main.c:2382 SISDoSense() warn: inconsistent indenting. drivers/video/fbdev/sis/sis_main.c:2250 sisfb_sense_crt1() warn: inconsistent indenting. drivers/video/fbdev/sis/sis_main.c:672 sisfb_validate_mode() warn: inconsistent indenting. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1934 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Helge Deller <deller@gmx.de>
2022-08-24fbdev: fb_pm2fb: Avoid potential divide by zero errorLetu Ren
In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be copied from user, then go through `fb_set_var()` and `info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`. Along the path, `var->pixclock` won't be modified. This function checks whether reciprocal of `var->pixclock` is too high. If `var->pixclock` is zero, there will be a divide by zero error. So, it is necessary to check whether denominator is zero to avoid crash. As this bug is found by Syzkaller, logs are listed below. divide error in pm2fb_check_var Call Trace: <TASK> fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Reported-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Letu Ren <fantasquex@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2022-08-24fbdev: ssd1307fb: Fix repeated words in commentsJilin Yuan
Delete the redundant word 'set'. Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com> Signed-off-by: Helge Deller <deller@gmx.de>
2022-08-24fbdev: omapfb: Fix tests for platform_get_irq() failureYu Zhe
The platform_get_irq() returns negative error codes. It can't actually return zero. Signed-off-by: Yu Zhe <yuzhe@nfschina.com> Signed-off-by: Helge Deller <deller@gmx.de>
2022-08-24i40e: Fix incorrect address type for IPv6 flow rulesSylwester Dziedziuch
It was not possible to create 1-tuple flow director rule for IPv6 flow type. It was caused by incorrectly checking for source IP address when validating user provided destination IP address. Fix this by changing ip6src to correct ip6dst address in destination IP address validation for IPv6 flow type. Fixes: efca91e89b67 ("i40e: Add flow director support for IPv6") Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-08-24ixgbe: stop resetting SYSTIME in ixgbe_ptp_start_cyclecounterJacob Keller
The ixgbe_ptp_start_cyclecounter is intended to be called whenever the cyclecounter parameters need to be changed. Since commit a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices"), this function has cleared the SYSTIME registers and reset the TSAUXC DISABLE_SYSTIME bit. While these need to be cleared during ixgbe_ptp_reset, it is wrong to clear them during ixgbe_ptp_start_cyclecounter. This function may be called during both reset and link status change. When link changes, the SYSTIME counter is still operating normally, but the cyclecounter should be updated to account for the possibly changed parameters. Clearing SYSTIME when link changes causes the timecounter to jump because the cycle counter now reads zero. Extract the SYSTIME initialization out to a new function and call this during ixgbe_ptp_reset. This prevents the timecounter adjustment and avoids an unnecessary reset of the current time. This also restores the original SYSTIME clearing that occurred during ixgbe_ptp_reset before the commit above. Reported-by: Steve Payne <spayne@aurora.tech> Reported-by: Ilya Evenbach <ievenbach@aurora.tech> Fixes: a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices") Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-08-24md: call __md_stop_writes in md_stopGuoqing Jiang
From the link [1], we can see raid1d was running even after the path raid_dtr -> md_stop -> __md_stop. Let's stop write first in destructor to align with normal md-raid to fix the KASAN issue. [1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a Fixes: 48df498daf62 ("md: move bitmap_destroy to the beginning of __md_stop") Reported-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev> Signed-off-by: Song Liu <song@kernel.org>
2022-08-24Revert "md-raid: destroy the bitmap after destroying the thread"Guoqing Jiang
This reverts commit e151db8ecfb019b7da31d076130a794574c89f6f. Because it obviously breaks clustered raid as noticed by Neil though it fixed KASAN issue for dm-raid, let's revert it and fix KASAN issue in next commit. [1]. https://lore.kernel.org/linux-raid/a6657e08-b6a7-358b-2d2a-0ac37d49d23a@linux.dev/T/#m95ac225cab7409f66c295772483d091084a6d470 Fixes: e151db8ecfb0 ("md-raid: destroy the bitmap after destroying the thread") Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev> Signed-off-by: Song Liu <song@kernel.org>
2022-08-24md: Flush workqueue md_rdev_misc_wq in md_alloc()David Sloan
A race condition still exists when removing and re-creating md devices in test cases. However, it is only seen on some setups. The race condition was tracked down to a reference still being held to the kobject by the rdev in the md_rdev_misc_wq which will be released in rdev_delayed_delete(). md_alloc() waits for previous deletions by waiting on the md_misc_wq, but the md_rdev_misc_wq may still be holding a reference to a recently removed device. To fix this, also flush the md_rdev_misc_wq in md_alloc(). Signed-off-by: David Sloan <david.sloan@eideticom.com> [logang@deltatee.com: rewrote commit message] Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Song Liu <song@kernel.org>
2022-08-24md/raid10: Fix the data type of an r10_sync_page_io() argumentBart Van Assche
Fix the following sparse warning: drivers/md/raid10.c:2647:60: sparse: sparse: incorrect type in argument 5 (different base types) @@ expected restricted blk_opf_t [usertype] opf @@ got int rw @@ This patch does not change any functionality since REQ_OP_READ = READ = 0 and since REQ_OP_WRITE = WRITE = 1. Cc: Rong A Chen <rong.a.chen@intel.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Paul Menzel <pmenzel@molgen.mpg.de> Fixes: 4ce4c73f662b ("md/core: Combine two sync_page_io() arguments") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Song Liu <song@kernel.org>
2022-08-24Merge branch 'dmi-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging Pull dmi update from Jean Delvare. Tiny cleanup. * 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging: firmware: dmi: Use the proper accessor for the version field
2022-08-24loop: Check for overflow while configuring loopSiddh Raman Pant
The userspace can configure a loop using an ioctl call, wherein a configuration of type loop_config is passed (see lo_ioctl()'s case on line 1550 of drivers/block/loop.c). This proceeds to call loop_configure() which in turn calls loop_set_status_from_info() (see line 1050 of loop.c), passing &config->info which is of type loop_info64*. This function then sets the appropriate values, like the offset. loop_device has lo_offset of type loff_t (see line 52 of loop.c), which is typdef-chained to long long, whereas loop_info64 has lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h). The function directly copies offset from info to the device as follows (See line 980 of loop.c): lo->lo_offset = info->lo_offset; This results in an overflow, which triggers a warning in iomap_iter() due to a call to iomap_iter_done() which has: WARN_ON_ONCE(iter->iomap.offset > iter->pos); Thus, check for negative value during loop_set_status_from_info(). Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e Reported-and-tested-by: syzbot+a8e049cd3abd342936b6@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Siddh Raman Pant <code@siddh.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220823160810.181275-1-code@siddh.me Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-08-24fec: Restart PPS after link state changeCsókás Bence
On link state change, the controller gets reset, causing PPS to drop out and the PHC to lose its time and calibration. So we restart it if needed, restoring calibration and time registers. Changes since v2: * Add `fec_ptp_save_state()`/`fec_ptp_restore_state()` * Use `ktime_get_real_ns()` * Use `BIT()` macro Changes since v1: * More ECR #define's * Stop PPS in `fec_ptp_stop()` Signed-off-by: Csókás Bence <csokas.bence@prolan.hu> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-23drm/i915/backlight: Disable pps power hook for aux based backlightJouni Högander
Pps power hook seems to be problematic for backlight controlled via aux channel. Disable it for such cases. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3657 Cc: stable@vger.kernel.org Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220822140836.534432-1-jouni.hogander@intel.com (cherry picked from commit 869e3bb7acb59d88c1226892136661810e8223a4) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-08-23drm/i915/display: avoid warnings when registering dual panel backlightArun R Murthy
Commit 20f85ef89d94 ("drm/i915/backlight: use unique backlight device names") added support for multiple backlight devices on dual panel systems, but did so with error handling on -EEXIST from backlight_device_register(). Unfortunately, that triggered a warning in dmesg all the way down from sysfs_add_file_mode_ns() and sysfs_warn_dup(). Instead of optimistically always attempting to register with the default name ("intel_backlight", which we have to retain for backward compatibility), check if a backlight device with the name exists first, and, if so, use the card and connector based name. v2: reworked on top of the patch commit 20f85ef89d94 ("drm/i915/backlight: use unique backlight device names") v3: fixed the ref count leak(Jani N) Fixes: 20f85ef89d94 ("drm/i915/backlight: use unique backlight device names") Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220808035750.3111046-1-arun.r.murthy@intel.com (cherry picked from commit 4234ea30051200fc6016de10e4d58369e60b38f1) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-08-23drm/i915/dsi: fix dual-link DSI backlight and CABC ports for display 11+Jani Nikula
The VBT dual-link DSI backlight and CABC still use ports A and C, both in Bspec and code, while display 11+ DSI only supports ports A and B. Assume port C actually means port B for display 11+ when parsing VBT. Bspec: 20154 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6476 Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8c462718bcc7b36a83e09d0a5eef058b6bc8b1a2.1660664162.git.jani.nikula@intel.com (cherry picked from commit ab55165d73a444606af1530cd0d6448b04370f68) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-08-23drm/i915/dsi: filter invalid backlight and CABC portsJani Nikula
Avoid using ports that aren't initialized in case the VBT backlight or CABC ports have invalid values. This fixes a NULL pointer dereference of intel_dsi->dsi_hosts[port] in such cases. Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b0f4f087866257d280eb97d6bcfcefd109cc5fa2.1660664162.git.jani.nikula@intel.com (cherry picked from commit f4a6c7a454a6e71c5ccf25af82694213a9784013) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-08-23drm/i915/guc: clear stalled request after a resetDaniele Ceraolo Spurio
If the GuC CTs are full and we need to stall the request submission while waiting for space, we save the stalled request and where the stall occurred; when the CTs have space again we pick up the request submission from where we left off. If a full GT reset occurs, the state of all contexts is cleared and all non-guilty requests are unsubmitted, therefore we need to restart the stalled request submission from scratch. To make sure that we do so, clear the saved request after a reset. Fixes note: the patch that introduced the bug is in 5.15, but no officially supported platform had GuC submission enabled by default in that kernel, so the backport to that particular version (and only that one) can potentially be skipped. Fixes: 925dc1cf58ed ("drm/i915/guc: Implement GuC submission tasklet") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Cc: <stable@vger.kernel.org> # v5.15+ Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220811210812.3239621-1-daniele.ceraolospurio@intel.com (cherry picked from commit f922fbb0f2ad1fd3e3186f39c46673419e6d9281) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-08-23drm/i915/ttm: fix CCS handlingMatthew Auld
Crucible + recent Mesa seems to sometimes hit: GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER) And it looks like we can also trigger this with gem_lmem_swapping, if we modify the test to use slightly larger object sizes. Looking closer it looks like we have the following issues in migrate_copy(): - We are using plain integer in various places, which we can easily overflow with a large object. - We pass the entire object size (when the src is lmem) into emit_pte() and then try to copy it, which doesn't work, since we only have a few fixed sized windows in which to map the pages and perform the copy. With an object > 8M we therefore aren't properly copying the pages. And then with an object > 64M we trigger the GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER). So it looks like our copy handling for any object > 8M (which is our CHUNK_SZ) is currently broken on DG2. Fixes: da0595ae91da ("drm/i915/migrate: Evict and restore the flatccs capable lmem obj") Testcase: igt@gem_lmem_swapping Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Ramalingam C<ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220805132240.442747-2-matthew.auld@intel.com (cherry picked from commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-08-23Merge tag 'mlx5-fixes-2022-08-22' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5 fixes 2022-08-22 This series provides bug fixes to mlx5 driver. * tag 'mlx5-fixes-2022-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net/mlx5: Unlock on error in mlx5_sriov_enable() net/mlx5e: Fix use after free in mlx5e_fs_init() net/mlx5e: kTLS, Use _safe() iterator in mlx5e_tls_priv_tx_list_cleanup() net/mlx5: unlock on error path in esw_vfs_changed_event_handler() net/mlx5e: Fix wrong tc flag used when set hw-tc-offload off net/mlx5e: TC, Add missing policer validation net/mlx5e: Fix wrong application of the LRO state net/mlx5: Avoid false positive lockdep warning by adding lock_class_key net/mlx5: Fix cmd error logging for manage pages cmd net/mlx5: Disable irq when locking lag_lock net/mlx5: Eswitch, Fix forwarding decision to uplink net/mlx5: LAG, fix logic over MLX5_LAG_FLAG_NDEVS_READY net/mlx5e: Properly disable vlan strip on non-UL reps ==================== Link: https://lore.kernel.org/r/20220822195917.216025-1-saeed@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-23Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== ice: xsk: reduced queue count fixes Maciej Fijalkowski says: this small series is supposed to fix the issues around AF_XDP usage with reduced queue count on interface. Due to the XDP rings setup, some configurations can result in sockets not seeing traffic flowing. More about this in description of patch 2. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: xsk: use Rx ring's XDP ring when picking NAPI context ice: xsk: prohibit usage of non-balanced queue id ==================== Link: https://lore.kernel.org/r/20220822163257.2382487-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-23clk: bcm: rpi: Show clock id limit in error caseStefan Wahren
The clock id limit will be extended in the future, so it would be helpful to see the actual clock id limit in case the firmware response has been rejected. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/20220713154953.3336-4-stefan.wahren@i2se.com Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Ivan T. Ivanov <iivanov@suse.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-23clk: bcm: rpi: Add missing newlineStefan Wahren
Some log messages lacks the final newline. So add them. Fixes: 93d2725affd6 ("clk: bcm: rpi: Discover the firmware clocks") Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/20220713154953.3336-3-stefan.wahren@i2se.com Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Ivan T. Ivanov <iivanov@suse.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-23clk: bcm: rpi: Prevent out-of-bounds accessStefan Wahren
The while loop in raspberrypi_discover_clocks() relies on the assumption that the id of the last clock element is zero. Because this data comes from the Videocore firmware and it doesn't guarantuee such a behavior this could lead to out-of-bounds access. So fix this by providing a sentinel element. Fixes: 93d2725affd6 ("clk: bcm: rpi: Discover the firmware clocks") Link: https://github.com/raspberrypi/firmware/issues/1688 Suggested-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/20220713154953.3336-2-stefan.wahren@i2se.com Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Ivan T. Ivanov <iivanov@suse.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-23bnxt_en: fix LRO/GRO_HW features in ndo_fix_features callbackVikas Gupta
LRO/GRO_HW should be disabled if there is an attached XDP program. BNXT_FLAG_TPA is the current setting of the LRO/GRO_HW. Using BNXT_FLAG_TPA to disable LRO/GRO_HW will cause these features to be permanently disabled once they are disabled. Fixes: 1dc4c557bfed ("bnxt: adding bnxt_xdp_build_skb to build skb from multibuffer xdp_buff") Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-23bnxt_en: fix NQ resource accounting during vf creation on 57500 chipsVikas Gupta
There are 2 issues: 1. We should decrement hw_resc->max_nqs instead of hw_resc->max_irqs with the number of NQs assigned to the VFs. The IRQs are fixed on each function and cannot be re-assigned. Only the NQs are being assigned to the VFs. 2. vf_msix is the total number of NQs to be assigned to the VFs. So we should decrement vf_msix from hw_resc->max_nqs. Fixes: b16b68918674 ("bnxt_en: Add SR-IOV support for 57500 chips.") Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-23bnxt_en: set missing reload flag in devlink featuresVikas Gupta
Add missing devlink_set_features() API for callbacks reload_down and reload_up to function. Fixes: 228ea8c187d8 ("bnxt_en: implement devlink dev reload driver_reinit") Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-23bnxt_en: Use PAGE_SIZE to init buffer when multi buffer XDP is not in usePavan Chebbi
Using BNXT_PAGE_MODE_BUF_SIZE + offset as buffer length value is not sufficient when running single buffer XDP programs doing redirect operations. The stack will complain on missing skb tail room. Fix it by using PAGE_SIZE when calling xdp_init_buff() for single buffer programs. Fixes: b231c3f3414c ("bnxt: refactor bnxt_rx_xdp to separate xdp_init_buff/xdp_prepare_buff") Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-23net: dsa: microchip: make learning configurable and keep it off while standaloneVladimir Oltean
Address learning should initially be turned off by the driver for port operation in standalone mode, then the DSA core handles changes to it via ds->ops->port_bridge_flags(). Leaving address learning enabled while ports are standalone breaks any kind of communication which involves port B receiving what port A has sent. Notably it breaks the ksz9477 driver used with a (non offloaded, ports act as if standalone) bonding interface in active-backup mode, when the ports are connected together through external switches, for redundancy purposes. This fixes a major design flaw in the ksz9477 and ksz8795 drivers, which unconditionally leave address learning enabled even while ports operate as standalone. Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477") Link: https://lore.kernel.org/netdev/CAFZh4h-JVWt80CrQWkFji7tZJahMfOToUJQgKS5s0_=9zzpvYQ@mail.gmail.com/ Reported-by: Brian Hutchinson <b.hutchman@gmail.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20220818164809.3198039-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-23Merge tag 'parisc-for-6.0-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: "Some interesting background to the current patchset: It turned out that the fldw instruction (which loads a 32-bit word from memory into one half of a FP register) failed on unaligned addresses and even trashed some other random FP register instead. It's a trivial one-liner fix in the exception handler but this failure dates back to the very beginnings of the parisc-port. It's strange that it was never noticed before. Another patch fixes an annoyance noticed by Randy Dunlap. Running "make ARCH=parisc64 randconfig" always returned a 32-bit config, although one would expect a 64-bit config. Masahiro Yamada suggested to mimik sparc Kconfig code, which fixed the issue nicely. This allowed to drop some compiler build checks too. Third, it's possible to build an optimized 32-bit kernel for PA8X00 (64-bit) CPUs, which then wouldn't start on 32-bit-only (PA1.x) machines. I've added a bootup check which prevents that and which prints a message to the console. This can be tested with qemu, which currently only supports 32-bit emulation. The other patches are usual clean-up stuff like added return value checks and typo fixes in comments. Summary: - Fix emulation of fldw instruction on unaligned addresses - Fix "make ARCH=parisc64 randconfig" to return a 64-bit config - Prevent boot if trying to boot a 32-bit kernel compiled for PA8X00 CPUs on 32-bit only machines - ccio-dma: Handle kmalloc failure in ccio_init_resources()" * tag 'parisc-for-6.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Add runtime check to prevent PA2.0 kernels on PA1.x machines parisc: ccio-dma: Handle kmalloc failure in ccio_init_resources() parisc: led: Move from strlcpy with unused retval to strscpy parisc: ccio-dma: Fix typo in comment Revert "parisc: Show error if wrong 32/64-bit compiler is being used" parisc: Make CONFIG_64BIT available for ARCH=parisc64 only parisc: Fix exception handler for fldw and fstw instructions
2022-08-23Merge tag 'mm-hotfixes-stable-2022-08-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "Thirteen fixes, almost all for MM. Seven of these are cc:stable and the remainder fix up the changes which went into this -rc cycle" * tag 'mm-hotfixes-stable-2022-08-22' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: kprobes: don't call disarm_kprobe() for disabled kprobes mm/shmem: shmem_replace_page() remember NR_SHMEM mm/shmem: tmpfs fallocate use file_modified() mm/shmem: fix chattr fsflags support in tmpfs mm/hugetlb: support write-faults in shared mappings mm/hugetlb: fix hugetlb not supporting softdirty tracking mm/uffd: reset write protection when unregister with wp-mode mm/smaps: don't access young/dirty bit if pte unpresent mm: add DEVICE_ZONE to FOR_ALL_ZONES kernel/sys_ni: add compat entry for fadvise64_64 mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW Revert "zram: remove double compression logic" get_maintainer: add Alan to .get_maintainer.ignore
2022-08-23Merge tag 'linux-kselftest-kunit-fixes-6.0-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull KUnit fixes from Shuah Khan: "Fix for a mmc test and to load .kunit_test_suites section when CONFIG_KUNIT=m, and not just when KUnit is built-in" * tag 'linux-kselftest-kunit-fixes-6.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: module: kunit: Load .kunit_test_suites section when CONFIG_KUNIT=m mmc: sdhci-of-aspeed: test: Fix dependencies when KUNIT=m
2022-08-23cpufreq: check only freq_table in __resolve_freq()Lukasz Luba
There is no need to check if the cpufreq driver implements callback cpufreq_driver::target_index. The logic in the __resolve_freq uses the frequency table available in the policy. It doesn't matter if the driver provides 'target_index' or 'target' callback. It just has to populate the 'policy->freq_table'. Thus, check only frequency table during the frequency resolving call. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-08-23thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTRLee, Chun-Yi
In some case, the GDDV returns a package with a buffer which has zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10). Then the data_vault_read() got NULL point dereference problem when accessing the 0x10 value in data_vault. [ 71.024560] BUG: kernel NULL pointer dereference, address: 0000000000000010 This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or NULL value in data_vault. Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-08-23Input: goodix - add compatible string for GT1158Jarrah Gosbell
Add compatible string for GT1158 missing from the previous patch. Fixes: 425fe4709c76 ("Input: goodix - add support for GT1158") Signed-off-by: Jarrah Gosbell <kernel@undef.tools> Link: https://lore.kernel.org/r/20220813043821.9981-1-kernel@undef.tools Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-08-23ACPI: processor: Remove freq Qos request for all CPUsRiwen Lu
The freq Qos request would be removed repeatedly if the cpufreq policy relates to more than one CPU. Then, it would cause the "called for unknown object" warning. Remove the freq Qos request for each CPU relates to the cpufreq policy, instead of removing repeatedly for the last CPU of it. Fixes: a1bb46c36ce3 ("ACPI: processor: Add QoS requests for all CPUs") Reported-by: Jeremy Linton <Jeremy.Linton@arm.com> Tested-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Riwen Lu <luriwen@kylinos.cn> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-08-23nouveau: explicitly wait on the fence in nouveau_bo_move_m2mfKarol Herbst
It is a bit unlcear to us why that's helping, but it does and unbreaks suspend/resume on a lot of GPUs without any known drawbacks. Cc: stable@vger.kernel.org # v5.15+ Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156 Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220819200928.401416-1-kherbst@redhat.com
2022-08-23soundwire: qcom: remove duplicate reset control getSrinivas Kandagatla
Looks like adding clock gate flag patch forgot to remove the old code that gets reset control. This causes below crash on platforms that do not need reset. [ 15.653501] reset_control_reset+0x124/0x170 [ 15.653508] qcom_swrm_init+0x50/0x1a0 [ 15.653514] qcom_swrm_probe+0x320/0x668 [ 15.653519] platform_probe+0x68/0xe0 [ 15.653529] really_probe+0xbc/0x2a8 [ 15.653535] __driver_probe_device+0x7c/0xe8 [ 15.653541] driver_probe_device+0x40/0x110 [ 15.653547] __device_attach_driver+0x98/0xd0 [ 15.653553] bus_for_each_drv+0x68/0xd0 [ 15.653559] __device_attach+0xf4/0x188 [ 15.653565] device_initial_probe+0x14/0x20 Fix this by removing old code. Reported-by: Amit Pundir <amit.pundir@linaro.org> Fixes: 1fd0d85affe4 ("soundwire: qcom: Add flag for software clock gating check") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Amit Pundir <amit.pundir@linaro.org> Link: https://lore.kernel.org/r/20220814123800.31200-1-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-08-23net: ipvtap - add __init/__exit annotations to module init/exit funcsMaciej Żenczykowski
Looks to have been left out in an oversight. Cc: Mahesh Bandewar <maheshb@google.com> Cc: Sainath Grandhi <sainath.grandhi@intel.com> Fixes: 235a9d89da97 ('ipvtap: IP-VLAN based tap driver') Signed-off-by: Maciej Żenczykowski <maze@google.com> Link: https://lore.kernel.org/r/20220821130808.12143-1-zenczykowski@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-08-23Revert "iommu/of: Delete usage of driver_deferred_probe_check_state()"Saravana Kannan
This reverts commit b09796d528bbf06e3e10a4a8f78038719da7ebc6. An issue was reported[1] on the original commit. I'll need to address that before I can delete the use of driver_deferred_probe_check_state(). So, bring it back for now. [1] - https://lore.kernel.org/lkml/4799738.LvFx2qVVIh@steina-w/ Fixes: b09796d528bb ("iommu/of: Delete usage of driver_deferred_probe_check_state()") Reported-by: Jean-Philippe Brucker <jpb@kernel.org> Tested-by: Jean-Philippe Brucker <jpb@kernel.org> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20220819221616.2107893-5-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-23Revert "PM: domains: Delete usage of driver_deferred_probe_check_state()"Saravana Kannan
This reverts commit 5a46079a96451cfb15e4f5f01f73f7ba24ef851a. Quite a few issues have been reported [1][2][3][4][5][6] on the original commit. While about half of them have been fixed, I'll need to fix the rest before driver_deferred_probe_check_state() can be deleted. So, revert the deletion for now. [1] - https://lore.kernel.org/all/DU0PR04MB941735271F45C716342D0410886B9@DU0PR04MB9417.eurprd04.prod.outlook.com/ [2] - https://lore.kernel.org/all/CM6REZS9Z8AC.2KCR9N3EFLNQR@otso/ [3] - https://lore.kernel.org/all/CAD=FV=XYVwaXZxqUKAuM5c7NiVjFz5C6m6gAHSJ7rBXBF94_Tg@mail.gmail.com/ [4] - https://lore.kernel.org/all/Yvpd2pwUJGp7R+YE@euler/ [5] - https://lore.kernel.org/lkml/20220601070707.3946847-2-saravanak@google.com/ [6] - https://lore.kernel.org/all/CA+G9fYt_cc5SiNv1Vbse=HYY_+uc+9OYPZuJ-x59bROSaLN6fw@mail.gmail.com/ Fixes: 5a46079a9645 ("PM: domains: Delete usage of driver_deferred_probe_check_state()") Reported-by: Peng Fan <peng.fan@nxp.com> Reported-by: Luca Weiss <luca.weiss@fairphone.com> Reported-by: Doug Anderson <dianders@chromium.org> Reported-by: Colin Foster <colin.foster@in-advantage.com> Reported-by: Tony Lindgren <tony@atomide.com> Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Peng Fan <peng.fan@nxp.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Tony Lindgren <tony@atomide.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20220819221616.2107893-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-23Revert "net: mdio: Delete usage of driver_deferred_probe_check_state()"Saravana Kannan
This reverts commit f8217275b57aa48d98cc42051c2aac34152718d6. There are a few more issues to fix that have been reported in the thread for the original series [1]. We'll need to fix those before this will work. So, revert it for now. [1] - https://lore.kernel.org/lkml/CAMuHMdWo_wRwV-i_iyTxVnEsf3Th9GBAG+wxUQMQGnw1t2ijTg@mail.gmail.com/ Fixes: f8217275b57a ("net: mdio: Delete usage of driver_deferred_probe_check_state()") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20220819221616.2107893-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-23Revert "driver core: Delete driver_deferred_probe_check_state()"Saravana Kannan
This reverts commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b. There are a few more issues to fix that have been reported in the thread for the original series [1]. We'll need to fix those before this will work. So, revert it for now. [1] - https://lore.kernel.org/lkml/20220601070707.3946847-1-saravanak@google.com/ Fixes: 9cbffc7a5956 ("driver core: Delete driver_deferred_probe_check_state()") Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Peng Fan <peng.fan@nxp.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20220819221616.2107893-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>