aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-01-25ACPI: NFIT: fix a potential deadlock during NFIT teardownVishal Verma1-1/+1
Lockdep reports that acpi_nfit_shutdown() may deadlock against an opportune acpi_nfit_scrub(). acpi_nfit_scrub () is run from inside a 'work' and therefore has already acquired workqueue-internal locks. It also acquiires acpi_desc->init_mutex. acpi_nfit_shutdown() first acquires init_mutex, and was subsequently attempting to cancel any pending workqueue items. This reversed locking order causes a potential deadlock: ====================================================== WARNING: possible circular locking dependency detected 6.2.0-rc3 #116 Tainted: G O N ------------------------------------------------------ libndctl/1958 is trying to acquire lock: ffff888129b461c0 ((work_completion)(&(&acpi_desc->dwork)->work)){+.+.}-{0:0}, at: __flush_work+0x43/0x450 but task is already holding lock: ffff888129b460e8 (&acpi_desc->init_mutex){+.+.}-{3:3}, at: acpi_nfit_shutdown+0x87/0xd0 [nfit] which lock already depends on the new lock. ... Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&acpi_desc->init_mutex); lock((work_completion)(&(&acpi_desc->dwork)->work)); lock(&acpi_desc->init_mutex); lock((work_completion)(&(&acpi_desc->dwork)->work)); *** DEADLOCK *** Since the workqueue manipulation is protected by its own internal locking, the cancellation of pending work doesn't need to be done under acpi_desc->init_mutex. Move cancel_delayed_work_sync() outside the init_mutex to fix the deadlock. Any work that starts after acpi_nfit_shutdown() drops the lock will see ARS_CANCEL, and the cancel_delayed_work_sync() will safely flush it out. Reported-by: Dan Williams <[email protected]> Signed-off-by: Vishal Verma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Williams <[email protected]>
2023-01-25dax: super.c: fix kernel-doc bad line warningRandy Dunlap1-1/+1
Convert an empty line to " *" to avoid a kernel-doc warning: drivers/dax/super.c:478: warning: bad line: Signed-off-by: Randy Dunlap <[email protected]> Cc: Dan Williams <[email protected]> Cc: Vishal Verma <[email protected]> Cc: Dave Jiang <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Williams <[email protected]>
2023-01-25bcache: Silence memcpy() run-time false positive warningsKees Cook2-2/+4
struct bkey has internal padding in a union, but it isn't always named the same (e.g. key ## _pad, key_p, etc). This makes it extremely hard for the compiler to reason about the available size of copies done against such keys. Use unsafe_memcpy() for now, to silence the many run-time false positive warnings: memcpy: detected field-spanning write (size 264) of single field "&i->j" at drivers/md/bcache/journal.c:152 (size 240) memcpy: detected field-spanning write (size 24) of single field "&b->key" at drivers/md/bcache/btree.c:939 (size 16) memcpy: detected field-spanning write (size 24) of single field "&temp.key" at drivers/md/bcache/extents.c:428 (size 16) Reported-by: Alexandre Pereira <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216785 Acked-by: Coly Li <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: [email protected] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-01-25gcc-plugins: Reorganize gimple includes for GCC 13Kees Cook1-2/+2
The gimple-iterator.h header must be included before gimple-fold.h starting with GCC 13. Reorganize gimple headers to work for all GCC versions. Reported-by: Palmer Dabbelt <[email protected]> Acked-by: Palmer Dabbelt <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2023-01-25kunit: memcpy: Split slow memcpy tests into MEMCPY_SLOW_KUNIT_TESTKees Cook2-0/+11
Since the long memcpy tests may stall a system for tens of seconds in virtualized architecture environments, split those tests off under CONFIG_MEMCPY_SLOW_KUNIT_TEST so they can be separately disabled. Reported-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/lkml/[email protected] Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-and-tested-by: Guenter Roeck <[email protected]> Reviewed-by: David Gow <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2023-01-25drm/amd/display: Fix timing not changning when freesync video is enabledAurabindo Pillai1-0/+7
[Why&How] Switching between certain modes that are freesync video modes and those are not freesync video modes result in timing not changing as seen by the monitor due to incorrect timing being driven. The issue is fixed by ensuring that when a non freesync video mode is set, we reset the freesync status on the crtc. Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Alan Liu <[email protected]> Signed-off-by: Aurabindo Pillai <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-25btrfs: zlib: zero-initialize zlib workspaceAlexander Potapenko1-1/+1
KMSAN reports uses of uninitialized memory in zlib's longest_match() called on memory originating from zlib_alloc_workspace(). This issue is known by zlib maintainers and is claimed to be harmless, but to be on the safe side we'd better initialize the memory. Link: https://zlib.net/zlib_faq.html#faq36 Reported-by: [email protected] CC: [email protected] # 5.4+ Signed-off-by: Alexander Potapenko <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2023-01-25btrfs: limit device extents to the device sizeJosef Bacik1-1/+5
There was a recent regression in btrfs/177 that started happening with the size class patches ("btrfs: introduce size class to block group allocator"). This however isn't a regression introduced by those patches, but rather the bug was uncovered by a change in behavior in these patches. The patches triggered more chunk allocations in the ^free-space-tree case, which uncovered a race with device shrink. The problem is we will set the device total size to the new size, and use this to find a hole for a device extent. However during shrink we may have device extents allocated past this range, so we could potentially find a hole in a range past our new shrink size. We don't actually limit our found extent to the device size anywhere, we assume that we will not find a hole past our device size. This isn't true with shrink as we're relocating block groups and thus creating holes past the device size. Fix this by making sure we do not search past the new device size, and if we wander into any device extents that start after our device size simply break from the loop and use whatever hole we've already found. CC: [email protected] # 4.14+ Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: David Sterba <[email protected]>
2023-01-25btrfs: raid56: fix stripes if vertical errors are foundTanmay Bhushan1-1/+1
We take two stripe numbers if vertical errors are found. In case it is just a pstripe it does not matter but in case of raid 6 it matters as both stripes need to be fixed. Fixes: 7a3150723061 ("btrfs: raid56: do data csum verification during RMW cycle") Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Tanmay Bhushan <[email protected]> Signed-off-by: David Sterba <[email protected]>
2023-01-25drm/display/dp_mst: Correct the kref of port.Wayne Lin1-1/+3
[why & how] We still need to refer to port while removing payload at commit_tail. we should keep the kref till then to release. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 Signed-off-by: Wayne Lin <[email protected]> Signed-off-by: Harry Wentland <[email protected]> Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic state") Cc: [email protected] # 6.1 Acked-by: Harry Wentland <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Tested-by: Didier Raboud <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-25drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPDWayne Lin1-2/+12
[Why & How] Now the vc_start_slot is controlled at drm side. When we service a long HPD, we still need to run dm_helpers_dp_mst_write_payload_allocation_table() to update drm mst_mgr's relevant variable. Otherwise, on the next plug-in, payload will get assigned with a wrong start slot. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 Signed-off-by: Wayne Lin <[email protected]> Signed-off-by: Harry Wentland <[email protected]> Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic state") Cc: [email protected] # 6.1 Acked-by: Harry Wentland <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Tested-by: Didier Raboud <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-25drm/amdgpu/display/mst: limit payload to be updated one by oneWayne Lin1-12/+39
[Why] amdgpu expects to update payload table for one stream one time by calling dm_helpers_dp_mst_write_payload_allocation_table(). Currently, it get modified to try to update HW payload table at once by referring mst_state. [How] This is just a quick workaround. Should find way to remove the temporary struct dc_dp_mst_stream_allocation_table later if set struct link_mst_stream_allocatio directly is possible. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 Signed-off-by: Wayne Lin <[email protected]> Signed-off-by: Harry Wentland <[email protected]> Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic state") Cc: [email protected] # 6.1 Acked-by: Harry Wentland <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Tested-by: Didier Raboud <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-25drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignmentsLyude Paul2-5/+24
Looks like I made a pretty big mistake here without noticing: it seems when I moved the assignments of mst_state->pbn_div I completely missed the fact that the reason for us calling drm_dp_mst_update_slots() earlier was to account for the fact that we need to call this function using info from the root MST connector, instead of just trying to do this from each MST encoder's atomic check function. Otherwise, we end up filling out all of DC's link information with zeroes. So, let's restore that and hopefully fix this DSC regression. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 Signed-off-by: Lyude Paul <[email protected]> Signed-off-by: Harry Wentland <[email protected]> Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic state") Cc: [email protected] # 6.1 Reviewed-by: Harry Wentland <[email protected]> Tested-by: Didier Raboud <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-25drm/amdgpu: declare firmware for new MES 11.0.4Li Ma1-0/+2
To support new mes ip block Signed-off-by: Li Ma <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-25drm/amdgpu: enable imu firmware for GC 11.0.4Li Ma1-0/+1
The GC 11.0.4 needs load IMU to power up GFX before loads GFX firmware. Signed-off-by: Li Ma <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-01-25drm/amd/pm: add missing AllowIHInterrupt message mapping for SMU13.0.0Evan Quan1-0/+1
Add SMU13.0.0 AllowIHInterrupt message mapping. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x
2023-01-25drm/amdgpu: remove unconditional trap enable on add gfx11 queuesJonathan Kim1-1/+0
Rebase of driver has incorrect unconditional trap enablement for GFX11 when adding mes queues. Reported-by: Graham Sider <[email protected]> Signed-off-by: Jonathan Kim <[email protected]> Reviewed-by: Graham Sider <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x
2023-01-25Merge tag 'fs.fuse.acl.v6.2-rc6' of ↵Linus Torvalds5-74/+78
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping Pull fuse ACL fix from Christian Brauner: "The new posix acl API doesn't depend on the xattr handler infrastructure anymore and instead only relies on the posix acl inode operations. As a result daemons without FUSE_POSIX_ACL are unable to use posix acls like they used to. Fix this by copying what we did for overlayfs during the posix acl api conversion. Make fuse implement a dedicated ->get_inode_acl() method as does overlayfs. Fuse can then also uses this to express different needs for vfs permission checking during lookup and acl based retrieval via the regular system call path. This allows fuse to continue to refuse retrieving posix acls for daemons that don't set FUSE_POSXI_ACL for permission checking while also allowing a fuse server to retrieve it via the usual system calls" * tag 'fs.fuse.acl.v6.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping: fuse: fixes after adapting to new posix acl api
2023-01-25selftests: amd-pstate: Don't delete source files via MakefileDoug Smythies1-5/+0
Revert the portion of a recent Makefile change that incorrectly deletes source files when doing "make clean". Fixes: ba2d788aa873 ("selftests: amd-pstate: Trigger tbench benchmark and test cpus") Reported-by: Sedat Dilek <[email protected]> Tested-by: Sedat Dilek <[email protected]> Reviewed-by: Sedat Dilek <[email protected]> Acked-by: Huang Rui <[email protected]> Signed-off-by: Doug Smythies <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2023-01-25cifs: Fix oops due to uncleared server->smbd_conn in reconnectDavid Howells1-0/+1
In smbd_destroy(), clear the server->smbd_conn pointer after freeing the smbd_connection struct that it points to so that reconnection doesn't get confused. Fixes: 8ef130f9ec27 ("CIFS: SMBD: Implement function to destroy a SMB Direct connection") Cc: [email protected] Reviewed-by: Paulo Alcantara (SUSE) <[email protected]> Acked-by: Tom Talpey <[email protected]> Signed-off-by: David Howells <[email protected]> Cc: Long Li <[email protected]> Cc: Pavel Shilovsky <[email protected]> Cc: Ronnie Sahlberg <[email protected]> Signed-off-by: Steve French <[email protected]>
2023-01-25bootconfig: Update MAINTAINERS file to add tree and mailing listMasami Hiramatsu (Google)1-0/+4
Since the bootconfig related changes will be handled on linux-trace tree, add the tree and mailing lists for EXTRA BOOT CONFIG. Link: https://lkml.kernel.org/r/167417138436.2333752.6988808113120359923.stgit@devnote3 Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2023-01-25rv: remove redundant initialization of pointer ptrColin Ian King1-1/+1
The pointer ptr is being initialized with a value that is never read, it is being updated later on a call to strim. Remove the extraneous initialization. Link: https://lkml.kernel.org/r/[email protected] Cc: Daniel Bristot de Oliveira <[email protected]> Cc: Masami Hiramatsu <[email protected]> Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2023-01-25ftrace: Maintain samples/ftraceMark Rutland1-0/+1
There's no entry in MAINTAINERS for samples/ftrace. Add one so that the FTRACE maintainers are kept in the loop. Link: https://lkml.kernel.org/r/[email protected] Acked-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Mark Rutland <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2023-01-25tracing/filter: fix kernel-doc warningsRandy Dunlap1-4/+4
Use the 'struct' keyword for a struct's kernel-doc notation and use the correct function parameter name to eliminate kernel-doc warnings: kernel/trace/trace_events_filter.c:136: warning: cannot understand function prototype: 'struct prog_entry ' kerne/trace/trace_events_filter.c:155: warning: Excess function parameter 'when_to_branch' description in 'update_preds' Also correct some trivial punctuation problems. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]>
2023-01-25riscv: Move call to init_cpu_topology() to later initialization stageLey Foon Tan1-1/+2
If "capacity-dmips-mhz" is present in a CPU DT node, topology_parse_cpu_capacity() will fail to allocate memory. arm64, with which this code path is shared, does not call topology_parse_cpu_capacity() until later in boot where memory allocation is available. While "capacity-dmips-mhz" is not yet a valid property on RISC-V, invalid properties should be ignored rather than cause issues. Move init_cpu_topology(), which calls topology_parse_cpu_capacity(), to a later initialization stage, to match arm64. As a side effect of this change, RISC-V is "protected" from changes to core topology code that would work on arm64 where memory allocation is safe but on RISC-V isn't. Fixes: 03f11f03dbfe ("RISC-V: Parse cpu topology during boot.") Reviewed-by: Conor Dooley <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Signed-off-by: Ley Foon Tan <[email protected]> Link: https://lore.kernel.org/r/[email protected] [Palmer: use Conor's commit text] Link: https://lore.kernel.org/linux-riscv/[email protected]/T/#me592d4c8b9508642954839f0077288a353b0b9b2 Signed-off-by: Palmer Dabbelt <[email protected]>
2023-01-25usb: gadget: f_uac2: Fix incorrect increment of bNumEndpointsPratham Pratap1-0/+1
Currently connect/disconnect of USB cable calls afunc_bind and eventually increments the bNumEndpoints. Performing multiple plugin/plugout will increment bNumEndpoints incorrectly, and on the next plug-in it leads to invalid configuration of descriptor and hence enumeration fails. Fix this by resetting the value of bNumEndpoints to 1 on every afunc_bind call. Fixes: 40c73b30546e ("usb: gadget: f_uac2: add adaptive sync support for capture") Cc: stable <[email protected]> Signed-off-by: Pratham Pratap <[email protected]> Signed-off-by: Prashanth K <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-25HID: Ignore battery for Elan touchscreen on Asus TP420IA[email protected]2-0/+3
This device has a touchscreen thats report a battery even if it doesn't have one. Ask Linux to ignore the battery so it will not always report it as low. [[email protected]: fix whitespace damage] Signed-off-by: Marco Rodolfi <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2023-01-25thermal: intel: int340x: Add locking to int340x_thermal_get_trip_type()Rafael J. Wysocki1-3/+7
In order to prevent int340x_thermal_get_trip_type() from possibly racing with int340x_thermal_read_trips() invoked by int3403_notify() add locking to it in analogy with int340x_thermal_get_trip_temp(). Fixes: 6757a7abe47b ("thermal: intel: int340x: Protect trip temperature from concurrent updates") Signed-off-by: Rafael J. Wysocki <[email protected]>
2023-01-25Merge branch 'mptcp-fixes'David S. Miller2-16/+28
Jeremy Kerr says: ==================== net: mctp: struct sock lifetime fixes This series is a set of fixes for the sock lifetime handling in the AF_MCTP code, fixing a uaf reported by Noam Rathaus <[email protected]>. The Fixes: tags indicate the original patches affected, but some tweaking to backport to those commits may be needed; I have a separate branch with backports to 5.15 if that helps with stable trees. Of course, any comments/queries most welcome. ==================== Signed-off-by: David S. Miller <[email protected]>
2023-01-25net: mctp: mark socks as dead on unhash, prevent re-addJeremy Kerr2-0/+7
Once a socket has been unhashed, we want to prevent it from being re-used in a sk_key entry as part of a routing operation. This change marks the sk as SOCK_DEAD on unhash, which prevents addition into the net's key list. We need to do this during the key add path, rather than key lookup, as we release the net keys_lock between those operations. Fixes: 4a992bbd3650 ("mctp: Implement message fragmentation & reassembly") Signed-off-by: Jeremy Kerr <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-01-25net: mctp: hold key reference when looking up a general keyPaolo Abeni1-7/+7
Currently, we have a race where we look up a sock through a "general" (ie, not directly associated with the (src,dest,tag) tuple) key, then drop the key reference while still holding the key's sock. This change expands the key reference until we've finished using the sock, and hence the sock reference too. Commit message changes from Jeremy Kerr <[email protected]>. Reported-by: Noam Rathaus <[email protected]> Fixes: 73c618456dc5 ("mctp: locking, lifetime and validity changes for sk_keys") Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Jeremy Kerr <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-01-25net: mctp: move expiry timer delete to unhashJeremy Kerr1-3/+6
Currently, we delete the key expiry timer (in sk->close) before unhashing the sk. This means that another thread may find the sk through its presence on the key list, and re-queue the timer. This change moves the timer deletion to the unhash, after we have made the key no longer observable, so the timer cannot be re-queued. Fixes: 7b14e15ae6f4 ("mctp: Implement a timeout for tags") Signed-off-by: Jeremy Kerr <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-01-25net: mctp: add an explicit reference from a mctp_sk_key to sockJeremy Kerr1-6/+8
Currently, we correlate the mctp_sk_key lifetime to the sock lifetime through the sock hash/unhash operations, but this is pretty tenuous, and there are cases where we may have a temporary reference to an unhashed sk. This change makes the reference more explicit, by adding a hold on the sock when it's associated with a mctp_sk_key, released on final key unref. Fixes: 73c618456dc5 ("mctp: locking, lifetime and validity changes for sk_keys") Signed-off-by: Jeremy Kerr <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-01-25Merge branch 'ravb-fixes'David S. Miller1-2/+8
Yoshihiro Shimoda says: ==================== net: ravb: Fix potential issues Fix potentiall issues on the ravb driver. Changes from v2: https://lore.kernel.org/all/[email protected]/ - Add Reviewed-by in the patch [2/2]. - Add a commit description in the patch [2/2]. Changes from v1: https://lore.kernel.org/all/[email protected]/ - Fix typo in the patch [1/2]. - Add Reviewed-by in the patch [1/2]. - Fix "Fixed" tag in the patch [2/2]. - Fix a comment indentation of the code in the patch [2/2]. ==================== Signed-off-by: David S. Miller <[email protected]>
2023-01-25net: ravb: Fix possible hang if RIS2_QFF1 happenYoshihiro Shimoda1-2/+2
Since this driver enables the interrupt by RIC2_QFE1, this driver should clear the interrupt flag if it happens. Otherwise, the interrupt causes to hang the system. Note that this also fix a minor coding style (a comment indentation) around the fixed code. Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Signed-off-by: Yoshihiro Shimoda <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-01-25net: ravb: Fix lack of register setting after system resumed for Gen3Yoshihiro Shimoda1-0/+6
After system entered Suspend to RAM, registers setting of this hardware is reset because the SoC will be turned off. On R-Car Gen3 (info->ccc_gac), ravb_ptp_init() is called in ravb_probe() only. So, after system resumed, it lacks of the initial settings for ptp. So, add ravb_ptp_{init,stop}() into ravb_{resume,suspend}(). Fixes: f5d7837f96e5 ("ravb: ptp: Add CONFIG mode support") Signed-off-by: Yoshihiro Shimoda <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-01-25gpio: ep93xx: Make irqchip immutableNikita Shubin1-13/+21
This turns the Cirrus ep93xx gpio irqchip immutable. Preserve per-chip labels by adding an ->irq_print_chip() callback. Signed-off-by: Nikita Shubin <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2023-01-25gpio: ep93xx: Fix port F hwirq numbers in handlerNikita Shubin1-1/+1
Fix wrong translation of irq numbers in port F handler, as ep93xx hwirqs increased by 1, we should simply decrease them by 1 in translation. Fixes: 482c27273f52 ("ARM: ep93xx: renumber interrupts") Signed-off-by: Nikita Shubin <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2023-01-25ASoC: codecs: wsa883x: correct playback min/max ratesKrzysztof Kozlowski1-2/+2
Correct reversed values used in min/max rates, leading to incorrect playback constraints. Cc: <[email protected]> Fixes: 43b8c7dc85a1 ("ASoC: codecs: add wsa883x amplifier support") Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-01-25gpio: mxc: Unlock on error path in mxc_flip_edge()Dan Carpenter1-1/+2
We recently added locking to this function but one error path was over looked. Drop the lock before returning. Fixes: e5464277625c ("gpio: mxc: Protect GPIO irqchip RMW with bgpio spinlock") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Marek Vasut <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2023-01-25platform/x86: thinkpad_acpi: Fix profile modes on Intel platformsMark Pearson1-5/+6
My last commit to fix profile mode displays on AMD platforms caused an issue on Intel platforms - sorry! In it I was reading the current functional mode (MMC, PSC, AMT) from the BIOS but didn't account for the fact that on some of our Intel platforms I use a different API which returns just the profile and not the functional mode. This commit fixes it so that on Intel platforms it knows the functional mode is always MMC. I also fixed a potential problem that a platform may try to set the mode for both MMC and PSC - which was incorrect. Tested on X1 Carbon 9 (Intel) and Z13 (AMD). Link: https://bugzilla.kernel.org/show_bug.cgi?id=216963 Fixes: fde5f74ccfc7 ("platform/x86: thinkpad_acpi: Fix profile mode display in AMT mode") Cc: [email protected] Reviewed-by: Mario Limonciello <[email protected]> Signed-off-by: Mark Pearson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2023-01-25net/x25: Fix to not accept on connected socketHyunwoo Kim1-0/+6
When listen() and accept() are called on an x25 socket that connect() succeeds, accept() succeeds immediately. This is because x25_connect() queues the skb to sk->sk_receive_queue, and x25_accept() dequeues it. This creates a child socket with the sk of the parent x25 socket, which can cause confusion. Fix x25_listen() to return -EINVAL if the socket has already been successfully connect()ed to avoid this issue. Signed-off-by: Hyunwoo Kim <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-01-25nvme: fix passthrough csi checkKeith Busch1-1/+1
The namespace head saves the Command Set Indicator enum, so use that instead of the Command Set Selected. The two values are not the same. Fixes: 831ed60c2aca2d ("nvme: also return I/O command effects from nvme_command_effects") Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2023-01-24riscv/kprobe: Fix instruction simulation of JALRLiao Chang1-2/+2
Set kprobe at 'jalr 1140(ra)' of vfs_write results in the following crash: [ 32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170 [ 32.093115] Oops [#1] [ 32.093251] Modules linked in: [ 32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16 [ 32.093985] Hardware name: riscv-virtio,qemu (DT) [ 32.094280] epc : ksys_read+0x88/0xd6 [ 32.094855] ra : ksys_read+0xc0/0xd6 [ 32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0 [ 32.095227] gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80 [ 32.095500] t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60 [ 32.095716] s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708 [ 32.095921] a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300 [ 32.096171] a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff [ 32.096411] s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170 [ 32.096638] s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030 [ 32.096865] s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410 [ 32.097092] s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c [ 32.097317] t5 : ffffffff8000c29c t6 : ffffffff800dbc54 [ 32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d [ 32.098011] [<ffffffff801cdb72>] ksys_write+0x6c/0xd6 [ 32.098222] [<ffffffff801cdc06>] sys_write+0x2a/0x38 [ 32.098405] [<ffffffff80003c76>] ret_from_syscall+0x0/0x2 Since the rs1 and rd might be the same one, such as 'jalr 1140(ra)', hence it requires obtaining the target address from rs1 followed by updating rd. Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported") Signed-off-by: Liao Chang <[email protected]> Reviewed-by: Guo Ren <[email protected]> Link: https://lore.kernel.org/r/[email protected] [Palmer: Pick Guo's cleanup] Signed-off-by: Palmer Dabbelt <[email protected]>
2023-01-24Merge branch 'bpf, sockmap: Fix infinite recursion in sock_map_close'Alexei Starovoitov4-47/+111
Jakub Sitnicki says: ==================== This patch set addresses the syzbot report in [1]. Patch #1 has been suggested by Eric [2]. I extended it to cover the rest of sock_map proto callbacks. Otherwise we would still overflow the stack. Patch #2 contains the actual fix and bug analysis. Patches #3 & #4 add coverage to selftests to trigger the bug. [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/all/CANn89iK2UN1FmdUcH12fv_xiZkv2G+Nskvmq7fG6aA_6VKRf6g@mail.gmail.com/ --- v1 -> v2: v1: https://lore.kernel.org/r/[email protected] [v1 didn't hit bpf@ ML by mistake] * pull in Eric's patch to protect against recursion loop bugs (Eric) * add a macro helper to check if pointer is inside a memory range (Eric) ==================== Signed-off-by: Alexei Starovoitov <[email protected]>
2023-01-24selftests/bpf: Cover listener cloning with progs attached to sockmapJakub Sitnicki1-2/+28
Today we test if a child socket is cloned properly from a listening socket inside a sockmap only when there are no BPF programs attached to the map. A bug has been reported [1] for the case when sockmap has a verdict program attached. So cover this case as well to prevent regressions. [1]: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Sitnicki <[email protected]> Acked-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2023-01-24selftests/bpf: Pass BPF skeleton to sockmap_listen ops testsJakub Sitnicki1-18/+37
Following patch extends the sockmap ops tests to cover the scenario when a sockmap with attached programs holds listening sockets. Pass the BPF skeleton to sockmap ops test so that the can access and attach the BPF programs. Signed-off-by: Jakub Sitnicki <[email protected]> Acked-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2023-01-24bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listenerJakub Sitnicki2-2/+14
A listening socket linked to a sockmap has its sk_prot overridden. It points to one of the struct proto variants in tcp_bpf_prots. The variant depends on the socket's family and which sockmap programs are attached. A child socket cloned from a TCP listener initially inherits their sk_prot. But before cloning is finished, we restore the child's proto to the listener's original non-tcp_bpf_prots one. This happens in tcp_create_openreq_child -> tcp_bpf_clone. Today, in tcp_bpf_clone we detect if the child's proto should be restored by checking only for the TCP_BPF_BASE proto variant. This is not correct. The sk_prot of listening socket linked to a sockmap can point to to any variant in tcp_bpf_prots. If the listeners sk_prot happens to be not the TCP_BPF_BASE variant, then the child socket unintentionally is left if the inherited sk_prot by tcp_bpf_clone. This leads to issues like infinite recursion on close [1], because the child state is otherwise not set up for use with tcp_bpf_prot operations. Adjust the check in tcp_bpf_clone to detect all of tcp_bpf_prots variants. Note that it wouldn't be sufficient to check the socket state when overriding the sk_prot in tcp_bpf_update_proto in order to always use the TCP_BPF_BASE variant for listening sockets. Since commit b8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage") it is possible for a socket to transition to TCP_LISTEN state while already linked to a sockmap, e.g. connect() -> insert into map -> connect(AF_UNSPEC) -> listen(). [1]: https://lore.kernel.org/all/[email protected]/ Fixes: e80251555f0b ("tcp_bpf: Don't let child socket inherit parent protocol ops on copy") Reported-by: [email protected] Signed-off-by: Jakub Sitnicki <[email protected]> Acked-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2023-01-24bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itselfJakub Sitnicki1-27/+34
sock_map proto callbacks should never call themselves by design. Protect against bugs like [1] and break out of the recursive loop to avoid a stack overflow in favor of a resource leak. [1] https://lore.kernel.org/all/[email protected]/ Suggested-by: Eric Dumazet <[email protected]> Signed-off-by: Jakub Sitnicki <[email protected]> Acked-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
2023-01-24Merge git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nfJakub Kicinski5-125/+77
Pablo Neira Ayuso says: ==================== Netfilter fixes for net 1) Perform SCTP vtag verification for ABORT/SHUTDOWN_COMPLETE according to RFC 9260, Sect 8.5.1. 2) Fix infinite loop if SCTP chunk size is zero in for_each_sctp_chunk(). And remove useless check in this macro too. 3) Revert DATA_SENT state in the SCTP tracker, this was applied in the previous merge window. Next patch in this series provides a more simple approach to multihoming support. 4) Unify HEARTBEAT_ACKED and ESTABLISHED states for SCTP multihoming support, use default ESTABLISHED of 210 seconds based on heartbeat timeout * maximum number of retransmission + round-trip timeout. Otherwise, SCTP conntrack entry that represents secondary paths remain stale in the table for up to 5 days. This is a slightly large batch with fixes for the SCTP connection tracking helper, all patches from Sriram Yagnaraman. * git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: conntrack: unify established states for SCTP paths Revert "netfilter: conntrack: add sctp DATA_SENT state" netfilter: conntrack: fix bug in for_each_sctp_chunk netfilter: conntrack: fix vtag checks for ABORT/SHUTDOWN_COMPLETE ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.