- 31 Dec, 2022 40 commits
-
-
Arun Easi authored
commit 68ad8318 upstream. While performing CPU hotplug, a crash with the following stack was seen: Call Trace: qla24xx_process_response_queue+0x42a/0x970 [qla2xxx] qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx] qla_nvme_post_cmd+0x166/0x240 [qla2xxx] nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc] blk_mq_dispatch_rq_list+0x17b/0x610 __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x35/0x90 __blk_mq_delay_run_hw_queue+0x161/0x180 blk_execute_rq+0xbe/0x160 __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core] nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics] nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc] nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc] process_one_work+0x1e8/0x3c0 On abort timeout, completion was called without checking if the I/O was already completed. Verify that I/O and abort request are indeed outstanding before attempting completion. Fixes: 71c80b75 ("scsi: qla2xxx: Do command completion on abort timeout") Reported-by:
Marco Patalano <mpatalan@redhat.com> Tested-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
Nilesh Javali <njavali@marvell.com> Link: https://lore.kernel.org/r/20221129092634.15347-1-njavali@marvell.com Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tetsuo Handa authored
commit 3c3bfb85 upstream. syzbot is reporting memory leak at fbcon_do_set_font() [1], for commit a5a92303 ("fbdev: fbcon: Properly revert changes when vc_resize() failed") missed that the buffer might be newly allocated by fbcon_set_font(). Link: https://syzkaller.appspot.com/bug?extid=25bdb7b1703639abd498 [1] Reported-by:
syzbot <syzbot+25bdb7b1703639abd498@syzkaller.appspotmail.com> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Yuan Can authored
commit f8ace2e3 upstream. A memory leak was reported when floppy_alloc_disk() failed in do_floppy_init(). unreferenced object 0xffff888115ed25a0 (size 8): comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s) hex dump (first 8 bytes): 00 ac 67 5b 81 88 ff ff ..g[.... backtrace: [<000000007f457abb>] __kmalloc_node+0x4c/0xc0 [<00000000a87bfa9e>] blk_mq_realloc_tag_set_tags.part.0+0x6f/0x180 [<000000006f02e8b1>] blk_mq_alloc_tag_set+0x573/0x1130 [<0000000066007fd7>] 0xffffffffc06b8b08 [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0 [<00000000e26d04ee>] do_init_module+0x1a4/0x680 [<000000001bb22407>] load_module+0x6249/0x7110 [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200 [<000000007bddca46>] do_syscall_64+0x35/0x80 [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 unreferenced object 0xffff88810fc30540 (size 32): comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007f457abb>] __kmalloc_node+0x4c/0xc0 [<000000006b91eab4>] blk_mq_alloc_tag_set+0x393/0x1130 [<0000000066007fd7>] 0xffffffffc06b8b08 [<0000000081f5ac40>] do_one_initcall+0xd0/0x4f0 [<00000000e26d04ee>] do_init_module+0x1a4/0x680 [<000000001bb22407>] load_module+0x6249/0x7110 [<00000000ad31ac4d>] __do_sys_finit_module+0x140/0x200 [<000000007bddca46>] do_syscall_64+0x35/0x80 [<00000000b5afec39>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 If the floppy_alloc_disk() failed, disks of current drive will not be set, thus the lastest allocated set->tag cannot be freed in the error handling path. A simple call graph shown as below: floppy_module_init() floppy_init() do_floppy_init() for (drive = 0; drive < N_DRIVE; drive++) blk_mq_alloc_tag_set() blk_mq_alloc_tag_set_tags() blk_mq_realloc_tag_set_tags() # set->tag allocated floppy_alloc_disk() blk_mq_alloc_disk() # error occurred, disks failed to allocated ->out_put_disk: for (drive = 0; drive < N_DRIVE; drive++) if (!disks[drive][0]) # the last disks is not set and loop break break; blk_mq_free_tag_set() # the latest allocated set->tag leaked Fix this problem by free the set->tag of current drive before jump to error handling path. Cc: stable@vger.kernel.org Fixes: 302cfee1 ("floppy: use a separate gendisk for each media format") Signed-off-by:
Yuan Can <yuancan@huawei.com> [efremov: added stable list, changed title] Signed-off-by:
Denis Efremov <efremov@linux.com> Signed-off-by:
-
Christophe Leroy authored
commit 3b553e00 upstream. Commit c9bfcb31 ("spi_mpc83xx: much improved driver") made modifications to the driver to not perform speed changes while chipselect is active. But those changes where lost with the convertion to tranfer_one. Previous implementation was allowing speed changes during message transfer when cs_change flag was set. At the time being, core SPI does not provide any feature to change speed while chipselect is off, so do not allow any speed change during message transfer, and perform the transfer setup in prepare_message in order to set correct speed while chipselect is still off. Reported-by:
Herve Codina <herve.codina@bootlin.com> Fixes: 64ca1a03 ("spi: fsl_spi: Convert to transfer_one") Cc: stable@vger.kernel.org Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Tested-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit cb3543cf upstream. When updating the operating mode as part of regulator enable, the caller has already locked the regulator tree and drms_uA_update() must not try to do the same in order not to trigger a deadlock. The lock inversion is reported by lockdep as: ====================================================== WARNING: possible circular locking dependency detected 6.1.0-next-20221215 #142 Not tainted ------------------------------------------------------ udevd/154 is trying to acquire lock: ffffc11f123d7e50 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x280 but task is already holding lock: ffff80000e4c36e8 (regulator_ww_class_acquire){+.+.}-{0:0}, at: regulator_enable+0x34/0x80 which lock already depends on the new lock. ... Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(regulator_ww_class_acquire); lock(regulator_list_mutex); lock(regulator_ww_class_acquire); lock(regulator_list_mutex); *** DEADLOCK *** just before probe of a Qualcomm UFS controller (occasionally) deadlocks when enabling one of its regulators. Fixes: 9243a195 ("regulator: core: Change voltage setting path") Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking") Cc: stable@vger.kernel.org # 5.0 Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20221215104646.19818-1-johan+linaro@kernel.org Signed-off-by:
-
Rasmus Villemoes authored
commit 980389d0 upstream. The constant AD74413R_ADC_RESULT_MAX is defined via GENMASK, so its type is "unsigned long". Hence in the expression voltage_offset * AD74413R_ADC_RESULT_MAX, voltage_offset is first promoted to unsigned long, and since it may be negative, that results in a garbage value. For example, when range is AD74413R_ADC_RANGE_5V_BI_DIR, voltage_offset is -2500 and voltage_range is 5000, so the RHS of this assignment is, depending on sizeof(long), either 826225UL or 3689348814709142UL, which after truncation to int then results in either 826225 or 1972216214 being the output from in_currentX_offset. Casting to int avoids that promotion and results in the correct -32767 output. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Fixes: fea251b6 (iio: addac: add AD74413R driver) Reviewed-by:
Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20221118123209.1658420-1-linux@rasmusvillemoes.dk Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Rasmus Villemoes authored
commit e2af60f5 upstream. Prior to commit bd5d54e4 ("iio: adc128s052: add ACPI _HID AANT1280"), the driver unconditionally used spi_get_device_id() to get the index into the adc128_config array. However, with that commit, OF-based boards now incorrectly treat all supported sensors as if they are an adc128s052, because all the .data members of the adc128_of_match table are implicitly 0. Our board, which has an adc122s021, thus exposes 8 channels whereas it really only has two. Fixes: bd5d54e4 ("iio: adc128s052: add ACPI _HID AANT1280") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221115132324.1078169-1-linux@rasmusvillemoes.dk Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Nuno Sá authored
commit 20228a1d upstream. Drop 'mlock' usage by making use of iio_device_claim_direct_mode(). This change actually makes sure we cannot do a single conversion while buffering is enable. Note there was a potential race in the previous code since we were only acquiring the lock after checking if the bus is enabled. Fixes: af300848 ("iio:adc: Add common code for ADI Sigma Delta devices") Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Cc: <Stable@vger.kernel.org> #No rush as race is very old. Link: https://lore.kernel.org/r/20220920112821.975359-2-nuno.sa@analog.com Signed-off-by:
-
Zeng Heng authored
commit 86fdd15e upstream. When iio_device_register_sysfs_group() returns failed, iio_device_register_eventset() needs to free attrs array. Otherwise, kmemleak would scan & report memory leak as below: unreferenced object 0xffff88810a1cc3c0 (size 32): comm "100-i2c-vcnl302", pid 728, jiffies 4295052307 (age 156.027s) backtrace: __kmalloc+0x46/0x1b0 iio_device_register_eventset at drivers/iio/industrialio-event.c:541 __iio_device_register at drivers/iio/industrialio-core.c:1959 __devm_iio_device_register at drivers/iio/industrialio-core.c:2040 Fixes: 32f17172 ("iio: core: rework iio device group creation") Signed-off-by:
Zeng Heng <zengheng4@huawei.com> Link: https://lore.kernel.org/r/20221115023712.3726854-1-zengheng4@huawei.com Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Isaac J. Manjarres authored
commit 85c50197 upstream. Currently, the max_loop commandline argument can be used to specify how many loop block devices are created at init time. If it is not specified on the commandline, CONFIG_BLK_DEV_LOOP_MIN_COUNT loop block devices will be created. The max_loop commandline argument can be used to override the value of CONFIG_BLK_DEV_LOOP_MIN_COUNT. However, when max_loop is set to 0 through the commandline, the current logic treats it as if it had not been set, and creates CONFIG_BLK_DEV_LOOP_MIN_COUNT devices anyway. Fix this by starting max_loop off as set to CONFIG_BLK_DEV_LOOP_MIN_COUNT. This preserves the intended behavior of creating CONFIG_BLK_DEV_LOOP_MIN_COUNT loop block devices if the max_loop commandline parameter is not specified, and allowing max_loop to be respected for all values, including 0. This allows environments that can create all of their required loop block devices on demand to not have to unnecessarily preallocate loop block devices. Fixes: 73285082 ("remove artificial software max_loop limit") Cc: stable@vger.kernel.org Cc: Ken Chen <kenchen@google.com> Signed-off-by:
Isaac J. Manjarres <isaacmanjarres@google.com> Link: https://lore.kernel.org/r/20221208212902.765781-1-isaacmanjarres@google.com Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Enrik Berkhan authored
commit 67c90d14 upstream. The MCP2221 driver should not connect to the hidraw userspace interface, as it needs exclusive access to the chip. If you want to use /dev/hidrawX with the MCP2221, you need to avoid binding this driver to the device and use the hid generic driver instead (e.g. using udev rules). Cc: stable@vger.kernel.org Reported-by:
Sven Zühlsdorf <sven.zuehlsdorf@vigem.de> Signed-off-by:
Enrik Berkhan <Enrik.Berkhan@inka.de> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221103222714.21566-2-Enrik.Berkhan@inka.de Signed-off-by:
-
Jason Gerecke authored
commit 1db1f392 upstream. Some Wacom devices have a special "bootloader" mode that is used for firmware flashing. When operating in this mode, the device cannot be used for input, and the HID descriptor is not able to be processed by the driver. The driver generates an "Unknown device_type" warning and then returns an error code from wacom_probe(). This is a problem because userspace still needs to be able to interact with the device via hidraw to perform the firmware flash. This commit adds a non-generic device definition for 056a:0094 which is used when devices are in "bootloader" mode. It marks the devices with a special BOOTLOADER type that is recognized by wacom_probe() and wacom_raw_event(). When we see this type we ensure a hidraw device is created and otherwise keep our hands off so that userspace is in full control. Signed-off-by:
Jason Gerecke <jason.gerecke@wacom.com> Tested-by:
Tatsunosuke Tobita <tatsunosuke.tobita@wacom.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Mathias Nyman authored
commit a1575120 upstream. Make sure to also limit the amount of soft reset retries for transaction errors on streams in cases where the transaction error event doesn't point to any specific TRB. In these cases we don't know the TRB or stream ring, but we do know which endpoint had the error. To keep error counting simple and functional, move the current err_count from ring structure to endpoint structure. Cc: stable@vger.kernel.org Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20221130091944.2171610-6-mathias.nyman@linux.intel.com Signed-off-by:
-
Miaoqian Lin authored
commit 97a48da1 upstream. of_icc_get() alloc resources for path handle, we should release it when not need anymore. Like the release in dwc3_qcom_interconnect_exit() function. Add icc_put() in error handling to fix this. Fixes: bea46b98 ("usb: dwc3: qcom: Add interconnect support in dwc3 driver") Cc: stable <stable@kernel.org> Acked-by:
Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20221206081731.818107-1-linmq006@gmail.com Signed-off-by:
-
Ferry Toth authored
commit 63130462 upstream. Since commit 0f010171 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present"), Dual Role support on Intel Merrifield platform broke due to rearranging the call to dwc3_get_extcon(). It appears to be caused by ulpi_read_id() masking the timeout on the first test write. In the past dwc3 probe continued by calling dwc3_core_soft_reset() followed by dwc3_get_extcon() which happend to return -EPROBE_DEFER. On deferred probe ulpi_read_id() finally succeeded. Due to above mentioned rearranging -EPROBE_DEFER is not returned and probe completes without phy. On Intel Merrifield the timeout on the first test write issue is reproducible but it is difficult to find the root cause. Using a mainline kernel and rootfs with buildroot ulpi_read_id() succeeds. As soon as adding ftrace / bootconfig to find out why, ulpi_read_id() fails and we can't analyze the flow. Using another rootfs ulpi_read_id() fails even without adding ftrace. We suspect the issue is some kind of timing / race, but merely retrying ulpi_read_id() does not resolve the issue. As we now changed ulpi_read_id() to return -ETIMEDOUT in this case, we need to handle the error by calling dwc3_core_soft_reset() and request -EPROBE_DEFER. On deferred probe ulpi_read_id() is retried and succeeds. Fixes: ef6a7bcf ("usb: ulpi: Support device discovery via DT") Cc: stable@vger.kernel.org Acked-by:
Ferry Toth <ftoth@exalondelft.nl> Link: https://lore.kernel.org/r/20221205201527.13525-3-ftoth@exalondelft.nl Signed-off-by:
-
Sven Peter authored
commit 62c73bfe upstream. dwc->desired_dr_role is changed by dwc3_set_mode inside a spinlock but then read by __dwc3_set_mode outside of that lock. This can lead to a race condition when very quick successive role switch events happen: CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_HOST) // first role switch event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_HOST spin_unlock_irqrestore(&dwc->lock, flags); queue_work(system_freezable_wq, &dwc->drd_work); CPU B __dwc3_set_mode // .... spin_lock_irqsave(&dwc->lock, flags); // desired_dr_role is DWC3_GCTL_PRTCAP_HOST dwc3_set_prtcap(dwc, dwc->desired_dr_role); spin_unlock_irqrestore(&dwc->lock, flags); CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_DEVICE) // second event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_DEVICE spin_unlock_irqrestore(&dwc->lock, flags); CPU B (continues running __dwc3_set_mode) switch (dwc->desired_dr_role) { // DWC3_GCTL_PRTCAP_DEVICE // .... case DWC3_GCTL_PRTCAP_DEVICE: // .... ret = dwc3_gadget_init(dwc); We then have DWC3_GCTL.DWC3_GCTL_PRTCAPDIR = DWC3_GCTL_PRTCAP_HOST and dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST but initialized the controller in device mode. It's also possible to get into a state where both host and device are intialized at the same time. Fix this race by creating a local copy of desired_dr_role inside __dwc3_set_mode while holding dwc->lock. Fixes: 41ce1456 ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@kernel.org> Acked-by:
Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20221128161526.79730-1-sven@svenpeter.dev Signed-off-by:
-
Li Jun authored
commit ed1f4ccf upstream. 32K usb suspend clock gate is shared with usb_root_clk, this shared clock gate was initially defined only for usb suspend clock, usb suspend clk is kept on while system is active or system sleep with usb wakeup enabled, so usb root clock is fine with this situation; with the commit cf7f3f4f ("clk: imx8mp: fix usb_root_clk parent"), this clock gate is changed to be for usb root clock, but usb root clock will be off while usb is suspended, so usb suspend clock will be gated too, this cause some usb functionalities will not work, so define this clock to be a shared clock gate to conform with the real HW status. Fixes: 9c140d99 ("clk: imx: Add support for i.MX8MP clock driver") Cc: stable@vger.kernel.org # v5.19+ Tested-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
Li Jun <jun.li@nxp.com> Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/1664549663-20364-2-git-send-email-jun.li@nxp.com Signed-off-by:
-
Chunfeng Yun authored
commit 03a88b0b upstream. Can not set the @shared_hcd to NULL before decrease the usage count by usb_put_hcd(), this will cause the shared hcd not released. Fixes: 04284eb7 ("usb: xhci-mtk: add support runtime PM") Cc: <stable@vger.kernel.org> Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20221128063337.18124-1-chunfeng.yun@mediatek.com Signed-off-by:
-
Pawel Laszczak authored
commit ae423ef5 upstream. Patch implements the handling of ZLP for control transfer. To send the ZLP driver must prepare the extra TRB in TD with length set to zero and TRB type to TRB_NORMAL. The first TRB must have set TRB_CHAIN flag, TD_SIZE = 1 and TRB type to TRB_DATA. Fixes: 3d829045 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") cc: <stable@vger.kernel.org> Reviewed-by:
Peter Chen <peter.chen@kernel.org> Signed-off-by:
Pawel Laszczak <pawell@cadence.com> Link: https://lore.kernel.org/r/20221122085138.332434-1-pawell@cadence.com Signed-off-by:
-
Bastien Nocera authored
commit 0e13e7b4 upstream. The Force Feedback code assumes that all the devices passed to it will be USB devices, but that might not be the case for emulated devices. Guard against a crash by checking the device type before poking at USB properties. Cc: stable@vger.kernel.org # v5.16+ Reported-by:
Bastien Nocera <hadess@hadess.net> Signed-off-by:
-
Jeff LaBundy authored
[ Upstream commit 8d4c313c ] IQS7222A revisions 1.13 and later widen the gesture multiplier from x4 ms to x16 ms. Add a means to scale the gesture timings specified in the device tree based on the revision of the device. Fixes: e505edae ("Input: add support for Azoteq IQS7222A/B/C") Signed-off-by:
Jeff LaBundy <jeff@labundy.com> Reviewed-by:
Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/Y1SRdbK1Dp2q7O8o@nixie71 Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jeff LaBundy authored
[ Upstream commit 404f3b48 ] Nonzero return values of several calls to fwnode_property_read_u32() are silently ignored, leaving no way to know the properties were not applied in the event of an error. Solve this problem by evaluating fwnode_property_read_u32()'s return value, and reporting an error for any nonzero return value not equal to -EINVAL which indicates the property was absent altogether. Fixes: e505edae ("Input: add support for Azoteq IQS7222A/B/C") Signed-off-by:
-
Jeff LaBundy authored
[ Upstream commit bbd16b0d ] Each call to device/fwnode_get_named_child_node() must be matched with a call to fwnode_handle_put() once the corresponding node is no longer in use. This ensures a reference count remains balanced in the case of dynamic device tree support. Currently, the driver never calls fwnode_handle_put(). Solve this problem by moving the node handling from iqs7222_parse_props() to the new iqs7222_parse_reg_grp(), leaving the former to do nothing but parse properties. The latter then manages the reference count in a single location and consistent fashion. This change drastically simplifies iqs7222_parse_all(), which can then call iqs7222_parse_reg_grp() on every register group without having to treat each register group differently. For nested event nodes, common parsing code has been factored out to the new iqs7222_parse_event() so as to allow the event node to be dropped from as few locations as possible. As part of this refactor, the 'linux,code' property has been made optional. This enables applications that define an event with the sole purpose of enabling a GPIO. Fixes: e505edae ("Input: add support for Azoteq IQS7222A/B/C") Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit d118b18f ] The activity_monitor_external[] array is too big to fit on the kernel stack, resulting in this warning with clang: drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_7_ppt.c:1438:12: error: stack frame size (1040) exceeds limit (1024) in 'smu_v13_0_7_get_power_profile_mode' [-Werror,-Wframe-larger-than] Use dynamic allocation instead. It should also be possible to have single element here instead of the array, but this seems easier. v2: fix up argument to sizeof() (Alex) Fixes: 334682ae ("drm/amd/pm: enable workload type change on smu_v13_0_7") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Kristina Martsenko authored
[ Upstream commit f68022ae ] The CFI test uses the branch-protection=none compiler attribute to disable PAC return address protection on a function. While newer GCC versions support this attribute, older versions (GCC 7 and 8) instead supported the sign-return-address=none attribute, leading to a build failure when the test is built with older compilers. Fix it by checking which attribute is supported and using the correct one. Fixes: 2e53b877 ("lkdtm: Add CFI_BACKWARD to test ROP mitigations") Reported-by:
Daniel Díaz <daniel.diaz@linaro.org> Signed-off-by:
Kristina Martsenko <kristina.martsenko@arm.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/all/CAEUSe78kDPxQmQqCWW-_9LCgJDFhAeMoVBFnX9QLx18Z4uT4VQ@mail.gmail.com/ Signed-off-by:
-
Khaled Almahallawy authored
[ Upstream commit 3153eebb ] Bspecs has updated recently to remove the restriction to disable DDI/Transcoder before setting PHY test pattern. This update is to address PHY compliance test failures observed on a port with LTTPR. The issue is that when Transc. is disabled, the main link signals fed to LTTPR will be dropped invalidating link training, which will affect the quality of the phy test pattern when the transcoder is enabled again. v2: Update commit message (Clint) v3: Add missing Signed-off in v2 v4: Update Bspec and commit message for pre-gen12 (Jani) Bspec: 50482, 7555 Fixes: 8cdf7271 ("drm/i915/dp: Program vswing, pre-emphasis, test-pattern") Cc: Imre Deak <imre.deak@intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> CC: Jani Nikula <jani.nikula@intel.com> Tested-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by:
Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123220926.170034-1-khaled.almahallawy@intel.com (cherry picked from commit be4a847652056b067d6dc6fe0fc024a9e2e987ca) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Yang Yingliang authored
[ Upstream commit b744db17 ] Add the missing unlock before return from function jc42_write() in the error handling case. Fixes: 37dedaee8bc6 ("hwmon: (jc42) Convert register access and caching to regmap/regcache") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20221027062931.598247-1-yangyingliang@huawei.com Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Maurizio Lombardi authored
[ Upstream commit fec1b2fa ] In case a malicious initiator sends some random data immediately after a login PDU; the iscsi_target_sk_data_ready() callback will schedule the login_work and, at the same time, the negotiation may end without clearing the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are required to complete the login). The login has been completed but the login_work function will find the LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling itself; at this point, if the initiator drops the connection, the iscsit_conn structure will be freed, login_work will dereference a released socket structure and the kernel crashes. BUG: kernel NULL pointer dereference, address: 0000000000000230 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod] RIP: 0010:_raw_read_lock_bh+0x15/0x30 Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0 Fix this bug by forcing login_work to stop after the login has been completed and the socket callbacks have been restored. Add a comment to clearify the return values of iscsi_target_do_login() Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Link: https://lore.kernel.org/r/20221115125638.102517-1-mlombard@redhat.com Reviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 0ad811cc ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hda_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_dvo_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hdmi_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ->mode_valid() in 'struct drm_connector_helper_funcs' expects a return type of 'enum drm_mode_status', not 'int'. Adjust the return type of sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to resolve the warning and CFI failure. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
-
Nathan Chancellor authored
[ Upstream commit 96d845a6 ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = fsl_dcu_drm_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. ->mode_valid() in 'struct drm_connector_helper_funcs' expects a return type of 'enum drm_mode_status', not 'int'. Adjust the return type of fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve the warning and CFI failure. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Reported-by:
Sami Tolvanen <samitolvanen@google.com> Signed-off-by:
-
Kumar Meiyappan authored
[ Upstream commit cc9befcb ] Correct device count for multi-actuator drives which can cause kernel panics. Reviewed-by:
Scott Benesh <scott.benesh@microchip.com> Reviewed-by:
Scott Teel <scott.teel@microchip.com> Reviewed-by:
Mike Mcgowan <mike.mcgowan@microchip.com> Reviewed-by:
Kevin Barnett <kevin.barnett@microchip.com> Signed-off-by:
Kumar Meiyappan <Kumar.Meiyappan@microchip.com> Signed-off-by:
Don Brace <don.brace@microchip.com> Link: https://lore.kernel.org/r/166793531872.322537.9003385780343419275.stgit@brunhilda Signed-off-by:
-
Mike McGowen authored
[ Upstream commit 0b93cf2a ] All PCI ID entries in Hex. Add PCI IDs for ByteDance controllers: VID / DID / SVID / SDID ---- ---- ---- ---- ByteHBA JGH43024-8 9005 / 028f / 1e93 / 1000 ByteHBA JGH43034-8 9005 / 028f / 1e93 / 1001 ByteHBA JGH44014-8 9005 / 028f / 1e93 / 1002 Add PCI IDs for new Inspur controllers: VID / DID / SVID / SDID ---- ---- ---- ---- INSPUR RT0800M7E 9005 / 028f / 1bd4 / 0086 INSPUR RT0800M7H 9005 / 028f / 1bd4 / 0087 INSPUR RT0804M7R 9005 / 028f / 1bd4 / 0088 INSPUR RT0808M7R 9005 / 028f / 1bd4 / 0089 Add PCI IDs for new FAB A controllers: VID / DID / SVID / SDID ---- ---- ---- ---- Adaptec SmartRAID 3254-16e /e 9005 / 028f / 9005 / 1475 Adaptec HBA 1200-16e 9005 / 028f / 9005 / 14c3 Adaptec HBA 1200-8e 9005 / 028f / 9005 / 14c4 Add H3C controller PCI IDs: VID / DID / SVID / SDID ---- ---- ---- ---- H3C H4508-Mf-8i 9005 / 028f / 193d / 110b Reviewed-by:
Mike McGowen <mike.mcgowen@microchip.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 3d75e766 ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/scsi/elx/libefc/efc_node.c:811:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] ctx->current_state = state; ^ ~~~~~ drivers/scsi/elx/libefc/efc_node.c:878:21: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] node->nodedb_state = state; ^ ~~~~~ drivers/scsi/elx/libefc/efc_node.c:905:6: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' from 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') [-Werror,-Wincompatible-function-pointer-types-strict] pf = node->nodedb_state; ^ ~~~~~~~~~~~~~~~~~~ drivers/scsi/elx/libefc/efc_device.c:455:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] node->nodedb_state = __efc_d_init; ^ ~~~~~~~~~~~~ drivers/scsi/elx/libefc/efc_sm.c:41:22: error: incompatible function pointer types assigning to 'void (*)(struct efc_sm_ctx *, u32, void *)' (aka 'void (*)(struct efc_sm_ctx *, unsigned int, void *)') from 'void (*)(struct efc_sm_ctx *, enum efc_sm_event, void *)' [-Werror,-Wincompatible-function-pointer-types-strict] ctx->current_state = state; ^ ~~~~~ The type of the second parameter in the prototypes of ->current_state() and ->nodedb_state() ('u32') does not match the implementations, which have a second parameter type of 'enum efc_sm_event'. Update the prototypes to have the correct second parameter type, clearing up all the warnings and CFI failures. Link: https://github.com/ClangBuiltLinux/linux/issues/1750 Reported-by:
-
Bjorn Helgaas authored
[ Upstream commit 44e98593 ] This reverts commit 6cd514e5. Christophe Fergeau reported that 6cd514e5 ("PCI: Clear PCI_STATUS when setting up device") causes boot failures when trying to start linux guests with Apple's virtualization framework (for example using https://developer.apple.com/documentation/virtualization/running_linux_in_a_virtual_machine?language=objc) 6cd514e5 only solved a cosmetic problem, so revert it to fix the boot failures. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2137803 Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Kai Ye authored
[ Upstream commit 3efe90af ] Increase the buffer to prevent stack overflow by fuzz test. The maximum length of the qos configuration buffer is 256 bytes. Currently, the value of the 'val buffer' is only 32 bytes. The sscanf does not check the dest memory length. So the 'val buffer' may stack overflow. Signed-off-by:
Kai Ye <yekai13@huawei.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit dcd5b763 ] Reduce the START STOP UNIT command timeout to one second since on Android devices a kernel panic is triggered if an attempt to suspend the system takes more than 20 seconds. One second should be enough for the START STOP UNIT command since this command completes in less than a millisecond for the UFS devices I have access to. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20221018202958.1902564-7-bvanassche@acm.org Signed-off-by:
-
Justin Tee authored
[ Upstream commit c44e50f4 ] During I/O and simultaneous cat of /sys/kernel/debug/lpfc/fnX/rx_monitor, a hard lockup similar to the call trace below may occur. The spin_lock_bh in lpfc_rx_monitor_report is not protecting from timer interrupts as expected, so change the strength of the spin lock to _irq. Kernel panic - not syncing: Hard LOCKUP CPU: 3 PID: 110402 Comm: cat Kdump: loaded exception RIP: native_queued_spin_lock_slowpath+91 [IRQ stack] native_queued_spin_lock_slowpath at ffffffffb814e30b _raw_spin_lock at ffffffffb89a667a lpfc_rx_monitor_record at ffffffffc0a73a36 [lpfc] lpfc_cmf_timer at ffffffffc0abbc67 [lpfc] __hrtimer_run_queues at ffffffffb8184250 hrtimer_interrupt at ffffffffb8184ab0 smp_apic_timer_interrupt at ffffffffb8a026ba apic_timer_interrupt at ffffffffb8a01c4f [End of IRQ stack] apic_timer_interrupt at ffffffffb8a01c4f lpfc_rx_monitor_report at ffffffffc0a73c80 [lpfc] lpfc_rx_monitor_read at ffffffffc0addde1 [lpfc] full_proxy_read at ffffffffb83e7fc3 vfs_read at ffffffffb833fe71 ksys_read at ffffffffb83402af do_syscall_64 at ffffffffb800430b entry_SYSCALL_64_after_hwframe at ffffffffb8a000ad Signed-off-by:
Justin Tee <justin.tee@broadcom.com> Link: https://lore.kernel.org/r/20221017164323.14536-2-justintee8345@gmail.com Signed-off-by:
-
Zhiqi Song authored
[ Upstream commit 45e6319b ] In hpre_remove(), when the disable operation of qm sriov failed, the following logic should continue to be executed to release the remaining resources that have been allocated, instead of returning directly, otherwise there will be resource leakage. Signed-off-by:
Zhiqi Song <songzhiqi1@huawei.com> Signed-off-by:
-
ChiYuan Huang authored
[ Upstream commit 0debed5b ] From Marek's log, the previous change modify the parent of rdev. https://lore.kernel.org/all/58b92e75-f373-dae7-7031-8abd465bb874@samsung.com/ In 'regulator_resolve_supply', it uses the parent DT node of rdev as the DT-lookup starting node. But the parent DT node may not exist. This will cause the NULL supply issue. This patch modify the parent of rdev back to the device that provides from 'regulator_config' in 'regulator_register'. Fixes: 8f3cbcd6 ("regulator: core: Use different devices for resource allocation and DT lookup") Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1670981831-12583-1-git-send-email-u0084500@gmail.com Signed-off-by:
-
Marek Vasut authored
[ Upstream commit 02d056a3 ] CYW4373A0 is a Wi-Fi + Bluetooth combo device from Cypress. This chip is present e.g. on muRata 2AE module. This chip has additional quirk where the HCI command 0xfc45, used on older chips to switch UART clock from 24 MHz to 48 MHz, to support baudrates over 3 Mbdps, is no longer recognized by this newer chip. This newer chip can configure the 4 Mbdps baudrate without the need to issue HCI command 0xfc45, so add flag to indicate this and do not issue the command on this chip to avoid failure to set 4 Mbdps baud rate. It is not clear whether there is a way to determine which chip does and which chip does not support the HCI command 0xfc45, other than trial and error. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
