summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-10-05efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock()Zhang Jianhua
While reboot the system by sysrq, the following bug will be occur. BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:90 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 10052, name: rc.shutdown CPU: 3 PID: 10052 Comm: rc.shutdown Tainted: G W O 5.10.0 #1 Call trace: dump_backtrace+0x0/0x1c8 show_stack+0x18/0x28 dump_stack+0xd0/0x110 ___might_sleep+0x14c/0x160 __might_sleep+0x74/0x88 down_interruptible+0x40/0x118 virt_efi_reset_system+0x3c/0xd0 efi_reboot+0xd4/0x11c machine_restart+0x60/0x9c emergency_restart+0x1c/0x2c sysrq_handle_reboot+0x1c/0x2c __handle_sysrq+0xd0/0x194 write_sysrq_trigger+0xbc/0xe4 proc_reg_write+0xd4/0xf0 vfs_write+0xa8/0x148 ksys_write+0x6c/0xd8 __arm64_sys_write+0x18/0x28 el0_svc_common.constprop.3+0xe4/0x16c do_el0_svc+0x1c/0x2c el0_svc+0x20/0x30 el0_sync_handler+0x80/0x17c el0_sync+0x158/0x180 The reason for this problem is that irq has been disabled in machine_restart() and then it calls down_interruptible() in virt_efi_reset_system(), which would occur sleep in irq context, it is dangerous! Commit 99409b935c9a("locking/semaphore: Add might_sleep() to down_*() family") add might_sleep() in down_interruptible(), so the bug info is here. down_trylock() can solve this problem, cause there is no might_sleep. -------- Cc: <stable@vger.kernel.org> Signed-off-by: Zhang Jianhua <chris.zjh@huawei.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2021-10-05efi/cper: use stack buffer for error record decodingArd Biesheuvel
Joe reports that using a statically allocated buffer for converting CPER error records into human readable text is probably a bad idea. Even though we are not aware of any actual issues, a stack buffer is clearly a better choice here anyway, so let's move the buffer into the stack frames of the two functions that refer to it. Cc: <stable@vger.kernel.org> Reported-by: Joe Perches <joe@perches.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2021-10-05efi/libstub: Simplify "Exiting bootservices" messageHeinrich Schuchardt
The message "Exiting boot services and installing virtual address map...\n" is even shown if we have efi=novamap on the command line or the firmware does not provide EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP. To avoid confusion just print "Exiting boot services...\n" Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2021-10-05staging: r8188eu: prevent array underflow in rtw_hal_update_ra_mask()Dan Carpenter
The problem is that "mac_id" is a u32 so this check for underflow does not work when "mac_id" is zero. In that situation, "mac_id - 1" is UINT_MAX instead of -1 so the condition is true. It leads to an array underflow on the next line. Fixes: 8cd574e6af54 ("staging: r8188eu: introduce new hal dir for RTL8188eu driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210930122604.GB10068@kili Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05staging: vc04_services: shut up out-of-range warningArnd Bergmann
The comparison against SIZE_MAX produces a harmless warning on 64-bit architectures: drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:185:16: error: result of comparison of constant 419244183493398898 with expression of type 'unsigned int' is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (num_pages > (SIZE_MAX - sizeof(struct pagelist) - ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Shut up that warning by adding a cast to a longer type. Fixes: ca641bae6da9 ("staging: vc04_services: prevent integer overflow in create_pagelist()") Cc: stable <stable@vger.kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210927113702.3866843-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-05afs: Fix afs_launder_page() to set correct start file positionDavid Howells
Fix afs_launder_page() to set the starting position of the StoreData RPC at the offset into the page at which the modified data starts instead of at the beginning of the page (the iov_iter is correctly offset). The offset got lost during the conversion to passing an iov_iter into afs_store_data(). Changes: ver #2: - Use page_offset() rather than manually calculating it[1]. Fixes: bd80d8a80e12 ("afs: Use ITER_XARRAY for writing") Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeffrey Altman <jaltman@auristor.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/YST/0e92OdSH0zjg@casper.infradead.org/ [1] Link: https://lore.kernel.org/r/162880783179.3421678.7795105718190440134.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/162937512409.1449272.18441473411207824084.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/162981148752.1901565.3663780601682206026.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/163005741670.2472992.2073548908229887941.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/163221839087.3143591.14278359695763025231.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/163292980654.4004896.7134735179887998551.stgit@warthog.procyon.org.uk/ # v2
2021-10-05netfs: Fix READ/WRITE confusion when calling iov_iter_xarray()David Howells
Fix netfs_clear_unread() to pass READ to iov_iter_xarray() instead of WRITE (the flag is about the operation accessing the buffer, not what sort of access it is doing to the buffer). Fixes: 3d3c95046742 ("netfs: Provide readahead and readpage netfs helpers") Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: linux-cachefs@redhat.com cc: linux-afs@lists.infradead.org cc: ceph-devel@vger.kernel.org cc: linux-cifs@vger.kernel.org cc: linux-nfs@vger.kernel.org cc: v9fs-developer@lists.sourceforge.net cc: linux-fsdevel@vger.kernel.org cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/162729351325.813557.9242842205308443901.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/162886603464.3940407.3790841170414793899.stgit@warthog.procyon.org.uk Link: https://lore.kernel.org/r/163239074602.1243337.14154704004485867017.stgit@warthog.procyon.org.uk
2021-10-05cachefiles: Fix oops with cachefiles_cull() due to NULL objectDave Wysochanski
When cachefiles_cull() calls cachefiles_bury_object(), it passes a NULL object. When this occurs, either trace_cachefiles_unlink() or trace_cachefiles_rename() may oops due to the NULL object. Check for NULL object in the tracepoint and if so, set debug_id to MAX_UINT as was done in 2908f5e101e3. The following oops was seen with xfstests generic/100. BUG: kernel NULL pointer dereference, address: 0000000000000010 ... RIP: 0010:trace_event_raw_event_cachefiles_unlink+0x4e/0xa0 [cachefiles] ... Call Trace: cachefiles_bury_object+0x242/0x430 [cachefiles] ? __vfs_removexattr_locked+0x10f/0x150 ? vfs_removexattr+0x51/0xd0 cachefiles_cull+0x84/0x120 [cachefiles] cachefiles_daemon_cull+0xd1/0x120 [cachefiles] cachefiles_daemon_write+0x158/0x190 [cachefiles] vfs_write+0xbc/0x260 ksys_write+0x4f/0xc0 do_syscall_64+0x3b/0x90 The following oops was seen with xfstests generic/290. BUG: kernel NULL pointer dereference, address: 0000000000000010 ... RIP: 0010:trace_event_raw_event_cachefiles_rename+0x54/0xa0 [cachefiles] ... Call Trace: cachefiles_bury_object+0x35c/0x430 [cachefiles] cachefiles_cull+0x84/0x120 [cachefiles] cachefiles_daemon_cull+0xd1/0x120 [cachefiles] cachefiles_daemon_write+0x158/0x190 [cachefiles] vfs_write+0xbc/0x260 ksys_write+0x4f/0xc0 do_syscall_64+0x3b/0x90 Fixes: 2908f5e101e3 ("fscache: Add a cookie debug ID and use that in traces") Signed-off-by: Dave Wysochanski <dwysocha@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://listman.redhat.com/archives/linux-cachefs/2021-October/msg00009.html
2021-10-05firmware: arm_ffa: Fix __ffa_devices_unregisterSudeep Holla
When arm_ffa firmware driver module is unloaded or removed we call __ffa_devices_unregister on all the devices on the ffa bus. It must unregister all the devices instead it is currently just releasing the devices without unregistering. That is pure wrong as when we try to load the module back again, it will result in the kernel crash something like below. -->8 CPU: 2 PID: 232 Comm: modprobe Not tainted 5.15.0-rc2+ #169 Hardware name: FVP Base RevC (DT) Call trace: dump_backtrace+0x0/0x1cc show_stack+0x18/0x64 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 sysfs_create_dir_ns+0xe4/0x140 kobject_add_internal+0x170/0x358 kobject_add+0x94/0x100 device_add+0x178/0x5f0 device_register+0x20/0x30 ffa_device_register+0x80/0xcc [ffa_module] ffa_setup_partitions+0x7c/0x108 [ffa_module] init_module+0x290/0x2dc [ffa_module] do_one_initcall+0xbc/0x230 do_init_module+0x58/0x304 load_module+0x15e0/0x1f68 __arm64_sys_finit_module+0xb8/0xf4 invoke_syscall+0x44/0x140 el0_svc_common+0xb4/0xf0 do_el0_svc+0x24/0x80 el0_svc+0x20/0x50 el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x1a0/0x1a4 kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to register things with the same name in the same directory. ---- Fix the issue by calling device_unregister in __ffa_devices_unregister which will also take care of calling device_release(which is mapped to ffa_release_device) Link: https://lore.kernel.org/r/20210924092859.3057562-2-sudeep.holla@arm.com Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration") Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-10-05firmware: arm_ffa: Add missing remove callback to ffa_bus_typeSudeep Holla
Currently the arm_ffa firmware driver can be built as module and hence all the users of FFA driver. If any driver on the ffa bus is removed or unregistered, the remove callback on all the device bound to the driver being removed should be callback. For that to happen, we must register a remove callback on the ffa_bus which is currently missing. This results in the probe getting called again without the previous remove callback on a device which may result in kernel crash. Fix the issue by registering the remove callback on the FFA bus. Link: https://lore.kernel.org/r/20210924092859.3057562-1-sudeep.holla@arm.com Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration") Reported-by: Jens Wiklander <jens.wiklander@linaro.org> Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-10-05Merge tag 'iio-fixes-for-5.15a' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: 1st set of IIO fixes for the 5.15 cycle Usual mixed back of minor bug fixes. adi,ad7192, ad7780, ad7793 * Fix incorrect IRQ_FLAG types. As the IRQ line is shared with the data line we can be sure of the polarity and edge like nature. They were previously either left unspecified or as level interrupts which may cause problems on power up. adi,adis16475 * Fix a deadlock by calling unlocked function when lock already held. Also deal with making sure lock is released correctly. adi,adis16480 * Fix assumption that all devices support sleep mode. aspeed,adc * Add missing platform_set_drvdata() so we can get the indio_dev in remove as was being assumed. fsl,fxls8962af * Return IRQ_HANDLED on flush rather than a positive 'error' code. maxim,max1207 * Fix a wrong shift on 12-bit devices that will lead to incorrect scale. * Fix wrong number of channels on max1X31 devices due to allocating them twice. mediatek,mt6577 * Fix a failure to apply scaling to IIO_CHAN_INFO_PROCESSED renesas,rzg2l * Fix failure to return -EBUSY on timeout due to ignored error code. * Add a missing clk_disable_unprepare() on error in runtime_resume. samsung,ssp_spi * Fix an error code to always be returned on invalid length. * Add some range checking to ensure resilience against bad data leading to potential overflow. ti,adc128s052 * Fix an error handling path that leaves regulator on if probe fails. ti,dac5571 * Add missing return value in a switch default. ti,opt3001 * Fix case where sensor returns 0 lux and we were previously accidentally returning that this was a timeout. * tag 'iio-fixes-for-5.15a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio: light: opt3001: Fixed timeout error when 0 lux iio: adis16480: fix devices that do not support sleep mode iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED iio: adis16475: fix deadlock on frequency set iio: ssp_sensors: add more range checking in ssp_parse_dataframe() iio: ssp_sensors: fix error code in ssp_print_mcu_debug() iio: adc: ad7793: Fix IRQ flag iio: adc: ad7780: Fix IRQ flag iio: adc: ad7192: Add IRQ flag iio: adc: aspeed: set driver data when adc probe. iio: adc: rzg2l_adc: add missing clk_disable_unprepare() in rzg2l_adc_pm_runtime_resume() iio: adc: max1027: Fix the number of max1X31 channels iio: adc: max1027: Fix wrong shift with 12-bit devices iio: adc128s052: Fix the error handling path of 'adc128_probe()' iio: adc: rzg2l_adc: Fix -EBUSY timeout error return iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushed iio: dac: ti-dac5571: fix an error code in probe()
2021-10-05drm/i915: Extend the async flip VT-d w/a to skl/bxtVille Syrjälä
Looks like skl/bxt/derivatives also need the plane stride stretch w/a when using async flips and VT-d is enabled, or else we get corruption on screen. To my surprise this was even documented in bspec, but only as a note on the CHICHKEN_PIPESL register description rather than on the w/a list. So very much the same thing as on HSW/BDW, except the bits moved yet again. Cc: stable@vger.kernel.org Cc: Karthik B S <karthik.b.s@intel.com> Fixes: 55ea1cb178ef ("drm/i915: Enable async flips in i915") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930190943.17547-1-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit d08df3b0bdb25546e86dc9a6c4e3ec0c43832299) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-05drm/i915/bdb: Fix version checkLukasz Majczak
With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+" the size of bdb_lfp_backlight_data structure has been increased, causing if-statement in the parse_lfp_backlight function that comapres this structure size to the one retrieved from BDB, always to fail for older revisions. This patch calculates expected size of the structure for a given BDB version and compares it with the value gathered from BDB. Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221) Fixes: d381baad29b4 ("drm/i915/vbt: Fix backlight parsing for VBT 234+") Tested-by: Lukasz Majczak <lma@semihalf.com> Signed-off-by: Lukasz Majczak <lma@semihalf.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930134606.227234-1-lma@semihalf.com (cherry picked from commit 4378daf5d04eed59724e6d0e74755e17dce2e105) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-05drm/i915/tc: Fix TypeC port init/resume time sanitizationImre Deak
Atm during driver loading and system resume TypeC ports are accessed before their HW/SW state is synced. Move the TypeC port sanitization to the encoder's sync_state hook to fix this. v2: Handle the encoder disabled case in gen11_dsi_sync_state() as well (Jose, Jani) Fixes: f9e76a6e68d3 ("drm/i915: Add an encoder hook to sanitize its state during init/resume") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929132833.2253961-1-imre.deak@intel.com (cherry picked from commit 7194dc998dfffca096c30b3cd39625158608992d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-05drm/i915: Fix runtime pm handling in i915_gem_shrinkMaarten Lankhorst
We forgot to call intel_runtime_pm_put on error, fix it! Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # v5.13+ Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210830121006.2978297-9-maarten.lankhorst@linux.intel.com (cherry picked from commit 239f3c2ee18376587026efecaea5250fa5926d20) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-05drm/i915/audio: Use BIOS provided value for RKL HDA linkKai-Heng Feng
Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver") makes HDMI audio on Lenovo P350 disappear. So in addition to TGL, extend the logic to RKL to use BIOS provided value to fix the regression. Fixes: 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver") Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210906041300.508458-1-kai.heng.feng@canonical.com (cherry picked from commit c6b40ee330fe09b332715bb7ec1467e4fcbe2e65) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-10-05ALSA: hda/realtek - ALC236 headset MIC recording issueKailang Yang
In power save mode, the recording voice from headset mic will 2s more delay. Add this patch will solve this issue. [ minor coding style fix by tiwai ] Signed-off-by: Kailang Yang <kailang@realtek.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/ccb0cdd5bbd7486eabbd8d987d384cb0@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-05xen/x86: adjust data placementJan Beulich
Both xen_pvh and xen_start_flags get written just once early during init. Using the respective annotation then allows the open-coded placing in .data to go away. Additionally the former, like the latter, wants exporting, or else xen_pvh_domain() can't be used from modules. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/8155ed26-5a1d-c06f-42d8-596d26e75849@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05x86/PVH: adjust function/data placementJan Beulich
Two of the variables can live in .init.data, allowing the open-coded placing in .data to go away. Another "variable" is used to communicate a size value only to very early assembly code, which hence can be both const and live in .init.*. Additionally two functions were lacking __init annotations. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/3b0bb22e-43f4-e459-c5cb-169f996b5669@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: hook up xen_banner() also for PVHJan Beulich
This was effectively lost while dropping PVHv1 code. Move the function and arrange for it to be called the same way as done in PV mode. Clearly this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad check that was recently removed, as that's a PV-only feature. Since the string pointed at by pv_info.name describes the mode, drop "paravirtualized" from the log message while moving the code. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/de03054d-a20d-2114-bb86-eec28e17b3b8@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: generalize preferred console model from PV to PVH Dom0Jan Beulich
Without announcing hvc0 as preferred it won't get used as long as tty0 gets registered earlier. This is particularly problematic with there not being any screen output for PVH Dom0 when the screen is in graphics mode, as the necessary information doesn't get conveyed yet from the hypervisor. Follow PV's model, but be conservative and do this for Dom0 only for now. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/582328b6-c86c-37f3-d802-5539b7a86736@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: make "earlyprintk=xen" work for HVM/PVH DomUJan Beulich
xenboot_write_console() is dealing with these quite fine so I don't see why xenboot_console_setup() would return -ENOENT in this case. Adjust documentation accordingly. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/3d212583-700e-8b2d-727a-845ef33ac265@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: allow "earlyprintk=xen" to work for PV Dom0Jan Beulich
With preferred consoles "tty" and "hvc" announced as preferred, registering "xenboot" early won't result in use of the console: It also needs to be registered as preferred. Generalize this from being DomU- only so far. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/d4a34540-a476-df2c-bca6-732d0d58c5f0@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: make "earlyprintk=xen" work better for PVH Dom0Jan Beulich
The xen_hvm_early_write() path better wouldn't be taken in this case; while port 0xE9 can be used, the hypercall path is quite a bit more efficient. Put that first, as it may also work for DomU-s (see also xen_raw_console_write()). While there also bail from the function when the first domU_write_console() failed - later ones aren't going to succeed. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/4fd89dcb-cfc5-c740-2e94-bb271e432d3e@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: allow PVH Dom0 without XEN_PV=yJan Beulich
Decouple XEN_DOM0 from XEN_PV, converting some existing uses of XEN_DOM0 to a new XEN_PV_DOM0. (I'm not convinced all are really / should really be PV-specific, but for starters I've tried to be conservative.) For PVH Dom0 the hypervisor populates MADT with only x2APIC entries, so without x2APIC support enabled in the kernel things aren't going to work very well. (As opposed, DomU-s would only ever see LAPIC entries in MADT as of now.) Note that this then requires PVH Dom0 to be 64-bit, as X86_X2APIC depends on X86_64. In the course of this xen_running_on_version_or_later() needs to be available more broadly. Move it from a PV-specific to a generic file, considering that what it does isn't really PV-specific at all anyway. Note that xen/interface/version.h cannot be included on its own; in enlighten.c, which uses SCHEDOP_* anyway, include xen/interface/sched.h first to resolve the apparently sole missing type (xen_ulong_t). Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/983bb72f-53df-b6af-14bd-5e088bd06a08@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/x86: prevent PVH type from getting clobberedJan Beulich
Like xen_start_flags, xen_domain_type gets set before .bss gets cleared. Hence this variable also needs to be prevented from getting put in .bss, which is possible because XEN_NATIVE is an enumerator evaluating to zero. Any use prior to init_hvm_pv_info() setting the variable again would lead to wrong decisions; one such case is xenboot_console_setup() when called as a result of "earlyprintk=xen". Use __ro_after_init as more applicable than either __section(".data") or __read_mostly. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/d301677b-6f22-5ae6-bd36-458e1f323d0b@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05arm64: dts: imx8m*-venice-gw7902: fix M2_RST# gpioTim Harvey
Fix invalid M2_RST# gpio pinmux. Fixes: ef484dfcf6f7 ("arm64: dts: imx: Add i.mx8mm/imx8mn Gateworks gw7902 dts support") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-10-05xen/privcmd: drop "pages" parameter from xen_remap_pfn()Jan Beulich
The function doesn't use it and all of its callers say in a comment that their respective arguments are to be non-NULL only in auto-translated mode. Since xen_remap_domain_mfn_array() isn't supposed to be used by non-PV, drop the parameter there as well. It was bogusly passed as non- NULL (PRIV_VMA_LOCKED) by its only caller anyway. For xen_remap_domain_gfn_range(), otoh, it's not clear at all why this wouldn't want / might not need to gain auto-translated support down the road, so the parameter is retained there despite now remaining unused (and the only caller passing NULL); correct a respective comment as well. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/036ad8a2-46f9-ac3d-6219-bdc93ab9e10b@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/privcmd: fix error handling in mmap-resource processingJan Beulich
xen_pfn_t is the same size as int only on 32-bit builds (and not even on Arm32). Hence pfns[] can't be used directly to read individual error values returned from xen_remap_domain_mfn_array(); every other error indicator would be skipped/ignored on 64-bit. Fixes: 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE") Cc: stable@vger.kernel.org Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/aa6d6a67-6889-338a-a910-51e889f792d5@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05xen/privcmd: replace kcalloc() by kvcalloc() when allocating empty pagesJan Beulich
Osstest has been suffering test failures for a little while from order-4 allocation failures, resulting from alloc_empty_pages() calling kcalloc(). As there's no need for physically contiguous space here, switch to kvcalloc(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/6d698901-98a4-05be-c421-bcd0713f5335@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-10-05ARM: imx6: disable the GIC CPU interface before calling stby-poweroff sequenceOleksij Rempel
Any pending interrupt can prevent entering standby based power off state. To avoid it, disable the GIC CPU interface. Fixes: 8148d2136002 ("ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-10-05ALSA: usb-audio: Enable rate validation for Scarlett devicesTakashi Iwai
The Scarlett device series from Focusrite Novation seem requiring the sample rate validations as we've done for MOTU devices; otherwise the driver probes invalid audioformat entries that contain the sample rates that actually don't work, and this may result in an incomplete setup as reported recently. This patch adds the needed quirk flag for enabling the sample rate validation for Focusrite Novation devices. Fixes: fe773b8711e3 ("ALSA: usb-audio: workaround for iface reset issue") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214493 Link: https://lore.kernel.org/r/20211004074050.28241-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-04scsi: iscsi: Fix iscsi_task use after freeMike Christie
Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but then also changed the handling of the case where we detect an already completed task where we now end up doing a goto to the common put/cleanup code. This results in a iscsi_task use after free, because the common cleanup code will do a put on the iscsi_task. This reverts the goto and moves the iscsi_get_conn() to after we've checked if the iscsi_task is valid. Link: https://lore.kernel.org/r/20211004210608.9962-1-michael.christie@oracle.com Fixes: d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-04scsi: lpfc: Fix memory overwrite during FC-GS I/O abort handlingJames Smart
When an FC-GS I/O is aborted by lpfc, the driver requires a node pointer for a dereference operation. In the abort I/O routine, the driver miscasts a context pointer to the wrong data type and overwrites a single byte outside of the allocated space. This miscast is done in the abort I/O function handler because the handler works on both FC-GS and FC-LS commands. However, the code neglected to get the correct job location for the node. Fix this by acquiring the necessary node pointer from the correct job structure depending on the I/O type. Link: https://lore.kernel.org/r/20211004231210.35524-1-jsmart2021@gmail.com Co-developed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-04scsi: elx: efct: Delete stray unlock statementDan Carpenter
It's not holding the lock at this stage and the IRQ "flags" are not correct so it would restore something bogus. Delete the unlock statement. Link: https://lore.kernel.org/r/20211004103851.GE25015@kili Fixes: 3e6414003bf9 ("scsi: elx: efct: SCSI I/O handling routines") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-04scsi: ufs: core: Fix task management completionAdrian Hunter
The UFS driver uses blk_mq_tagset_busy_iter() when identifying task management requests to complete, however blk_mq_tagset_busy_iter() doesn't work. blk_mq_tagset_busy_iter() only iterates requests dispatched by the block layer. That appears as if it might have started since commit 37f4a24c2469 ("blk-mq: centralise related handling into blk_mq_get_driver_tag") which removed 'data->hctx->tags->rqs[rq->tag] = rq' from blk_mq_rq_ctx_init() which gets called: blk_get_request blk_mq_alloc_request __blk_mq_alloc_request blk_mq_rq_ctx_init Since UFS task management requests are not dispatched by the block layer, hctx->tags->rqs[rq->tag] remains NULL, and since blk_mq_tagset_busy_iter() relies on finding requests using hctx->tags->rqs[rq->tag], UFS task management requests are never found by blk_mq_tagset_busy_iter(). By using blk_mq_tagset_busy_iter(), the UFS driver was relying on internal details of the block layer, which was fragile and subsequently got broken. Fix by removing the use of blk_mq_tagset_busy_iter() and having the driver keep track of task management requests. Link: https://lore.kernel.org/r/20210922091059.4040-1-adrian.hunter@intel.com Fixes: 1235fc569e0b ("scsi: ufs: core: Fix task management request completion timeout") Fixes: 69a6c269c097 ("scsi: ufs: Use blk_{get,put}_request() to allocate and free TMFs") Cc: stable@vger.kernel.org Tested-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-04scsi: acornscsi: Remove scsi_cmd_to_tag() referenceJohn Garry
Commit 756fb6a895af ("scsi: acornscsi: Remove tagged queuing vestiges") mistakenly introduced a reference to function scsi_cmd_to_tag(). This function does not exist as it was removed from an earlier series version when I upstreamed the named commit - originally authored By Hannes - but this reference still remained. Fix by replacing the reference to scsi_cmd_to_tag() with scsi_cmd_to_rq(scsi_scmd)->tag, which scsi_cmd_to_tag() was a wrapper for. Link: https://lore.kernel.org/r/1633002717-79765-1-git-send-email-john.garry@huawei.com Fixes: 756fb6a895af ("scsi: acornscsi: Remove tagged queuing vestiges") Reported-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-04riscv: Flush current cpu icache before other cpusAlexandre Ghiti
On SiFive Unmatched, I recently fell onto the following BUG when booting: [ 0.000000] ftrace: allocating 36610 entries in 144 pages [ 0.000000] Oops - illegal instruction [#1] [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5 [ 0.000000] Hardware name: SiFive HiFive Unmatched A00 (DT) [ 0.000000] epc : riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ra : __sbi_rfence_v02+0xc8/0x10a [ 0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10 [ 0.000000] gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000 [ 0.000000] t1 : 0000000000000004 t2 : 0000000000000000 s0 : ffffffff81803e60 [ 0.000000] s1 : 0000000000000000 a0 : ffffffff81a22238 a1 : ffffffff81803e10 [ 0.000000] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.000000] a5 : 0000000000000000 a6 : ffffffff8000989c a7 : 0000000052464e43 [ 0.000000] s2 : ffffffff81a220c8 s3 : 0000000000000000 s4 : 0000000000000000 [ 0.000000] s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001 [ 0.000000] s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000 [ 0.000000] s11: 0000000000000004 t3 : 0000000000000001 t4 : 0000000000000008 [ 0.000000] t5 : ffffffcf04000808 t6 : ffffffe3ffddf188 [ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000002 [ 0.000000] [<ffffffff80007240>] riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] [<ffffffff80009474>] sbi_remote_fence_i+0x1e/0x26 [ 0.000000] [<ffffffff8000b8f4>] flush_icache_all+0x12/0x1a [ 0.000000] [<ffffffff8000666c>] patch_text_nosync+0x26/0x32 [ 0.000000] [<ffffffff8000884e>] ftrace_init_nop+0x52/0x8c [ 0.000000] [<ffffffff800f051e>] ftrace_process_locs.isra.0+0x29c/0x360 [ 0.000000] [<ffffffff80a0e3c6>] ftrace_init+0x80/0x130 [ 0.000000] [<ffffffff80a00f8c>] start_kernel+0x5c4/0x8f6 [ 0.000000] ---[ end trace f67eb9af4d8d492b ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- While ftrace is looping over a list of addresses to patch, it always failed when patching the same function: riscv_cpuid_to_hartid_mask. Looking at the backtrace, the illegal instruction is encountered in this same function. However, patch_text_nosync, after patching the instructions, calls flush_icache_range. But looking at what happens in this function: flush_icache_range -> flush_icache_all -> sbi_remote_fence_i -> __sbi_rfence_v02 -> riscv_cpuid_to_hartid_mask The icache and dcache of the current cpu are never synchronized between the patching of riscv_cpuid_to_hartid_mask and calling this same function. So fix this by flushing the current cpu's icache before asking for the other cpus to do the same. Signed-off-by: Alexandre Ghiti <alex@ghiti.fr> Fixes: fab957c11efe ("RISC-V: Atomic and Locking Code") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-10-04Merge remote-tracking branch 'palmer/riscv-clone3' into fixesPalmer Dabbelt
This contains a single patch to properly implement clone3() on rv32, which was missing before. In theory this is a new feature, but it's fixing a warning in checksyscalls that's now causing my build to fail so I'm calling it a fix.
2021-10-04RISC-V: Include clone3() on rv32Palmer Dabbelt
As far as I can tell this should be enabled on rv32 as well, I'm not sure why it's rv64-only. checksyscalls is complaining about our lack of clone3() on rv32. Fixes: 56ac5e213933 ("riscv: enable sys_clone3 syscall for rv64") Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-10-04Merge tag 'linux-kselftest-fixes-5.15-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull Kselftest fixes from Shuah Khan: "A fix to implicit declaration warns in drivers/dma-buf test" * tag 'linux-kselftest-fixes-5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: selftests: drivers/dma-buf: Fix implicit declaration warns
2021-10-04fscache: Remove an unused static variableDavid Howells
The fscache object CREATE_OBJECT work state isn't ever referred to, so remove it and avoid the unused variable warning caused by W=1. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2
2021-10-04fscache: Fix some kerneldoc warnings shown up by W=1David Howells
Fix some kerneldoc warnings in the fscache driver that are shown up by W=1. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: Mauro Carvalho Chehab <mchehab@kernel.org> cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2
2021-10-049p: Fix a bunch of kerneldoc warnings shown up by W=1David Howells
Fix a bunch of kerneldoc warnings shown up by W=1 in the 9p filesystem: (1) Add/remove/fix kerneldoc parameters descriptions. (2) Move __add_fid() from between v9fs_fid_add() and its comment. (3) 9p's caches_show() doesn't really make sense as an API function, so remove the kerneldoc annotation. It's also not prefixed with 'v9fs_'. Also remove the kerneldoc markers from the 9p fscache wrappers. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Dominique Martinet <asmadeus@codewreck.org> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: Mauro Carvalho Chehab <mchehab@kernel.org> cc: v9fs-developer@lists.sourceforge.net cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2
2021-10-04afs: Fix kerneldoc warning shown up by W=1David Howells
Fix a kerneldoc warning in afs due to a partially documented internal function by removing the kerneldoc marker. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2
2021-10-04nfs: Fix kerneldoc warning shown up by W=1David Howells
Fix a kerneldoc warning in nfs due to documentation for a parameter that isn't present. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: Trond Myklebust <trond.myklebust@hammerspace.com> cc: Anna Schumaker <anna.schumaker@netapp.com> cc: Mauro Carvalho Chehab <mchehab@kernel.org> cc: linux-nfs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/163214005516.2945267.7000234432243167892.stgit@warthog.procyon.org.uk/ # rfc v1 Link: https://lore.kernel.org/r/163281899704.2790286.9177774252843775348.stgit@warthog.procyon.org.uk/ # rfc v2
2021-10-04i2c: mlxcpld: Modify register setting for 400KHz frequencyVadim Pasternak
Change setting for 400KHz frequency support by more accurate value. Fixes: 66b0c2846ba8 ("i2c: mlxcpld: Add support for I2C bus frequency setting") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2021-10-04i2c: mlxcpld: Fix criteria for frequency settingVadim Pasternak
Value for getting frequency capability wrongly has been taken from register offset instead of register value. Fixes: 66b0c2846ba8 ("i2c: mlxcpld: Add support for I2C bus frequency setting") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2021-10-04dt-bindings: drm/bridge: ti-sn65dsi86: Fix reg valueGeert Uytterhoeven
make dtbs_check: arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dt.yaml: bridge@2c: reg:0:0: 45 was expected According to the datasheet, the I2C address can be either 0x2c or 0x2d, depending on the ADDR control input. Fixes: e3896e6dddf0b821 ("dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Link: https://lore.kernel.org/r/08f73c2aa0d4e580303357dfae107d084d962835.1632486753.git.geert+renesas@glider.be Signed-off-by: Rob Herring <robh@kernel.org>
2021-10-04Merge tag 'media/v5.15-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media fix from Mauro Carvalho Chehab: "There's just one patch here, fixing a -Werror issue at staging/atomisp" * tag 'media/v5.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: media: atomisp: restore missing 'return' statement
generated by cgit (git 2.34.1) at 2025-09-12 21:26:58 +0000