aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-07-24drm/amdgpu: Fix atomics on GFX12David Belanger8-1/+143
If PCIe supports atomics, configure register to prevent DF from breaking atomics in separate load/store operations. Signed-off-by: David Belanger <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 666f14cab21b17ccc1bdfe1e82458aa429b3b7e0)
2024-07-24drm/amdgpu/sdma5.2: Update wptr registers as well as doorbellAlex Deucher1-0/+12
We seem to have a case where SDMA will sometimes miss a doorbell if GFX is entering the powergating state when the doorbell comes in. To workaround this, we can update the wptr via MMIO, however, this is only safe because we disallow gfxoff in begin_ring() for SDMA 5.2 and then allow it again in end_ring(). Enable this workaround while we are root causing the issue with the HW team. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/3440 Tested-by: Friedrich Vock <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] (cherry picked from commit f2ac52634963fc38e4935e11077b6f7854e5d700)
2024-07-24Merge tag 'phy-for-6.11' of ↵Linus Torvalds41-452/+4923
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy Pull phy updates from Vinod Koul: "New Support - Samsung Exynos gs101 drd combo phy - Qualcomm SC8180x USB uniphy, IPQ9574 QMP PCIe phy - Airoha EN7581 PCIe phy - Freescale i.MX8Q HSIO SerDes phy - Starfive jh7110 dphy tx Updates: - Resume support for j721e-wiz driver - Updates to Exynos usbdrd driver - Support for optional power domains in g12a usb2-phy driver - Debugfs support and updates to zynqmp driver" * tag 'phy-for-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (56 commits) phy: airoha: Add dtime and Rx AEQ IO registers dt-bindings: phy: airoha: Add dtime and Rx AEQ IO registers dt-bindings: phy: rockchip-emmc-phy: Convert to dtschema dt-bindings: phy: qcom,qmp-usb: fix spelling error phy: exynos5-usbdrd: support Exynos USBDRD 3.1 combo phy (HS & SS) phy: exynos5-usbdrd: convert Vbus supplies to regulator_bulk phy: exynos5-usbdrd: convert (phy) register access clock to clk_bulk phy: exynos5-usbdrd: convert core clocks to clk_bulk phy: exynos5-usbdrd: support isolating HS and SS ports independently dt-bindings: phy: samsung,usb3-drd-phy: add gs101 compatible phy: core: Fix documentation of of_phy_get phy: starfive: Correct the dphy configure process phy: zynqmp: Add debugfs support phy: zynqmp: Take the phy mutex in xlate phy: zynqmp: Only wait for PLL lock "primary" instances phy: zynqmp: Store instance instead of type phy: zynqmp: Enable reference clock correctly phy: cadence-torrent: Check return value on register read phy: Fix the cacography in phy-exynos5250-usb2.c phy: phy-rockchip-samsung-hdptx: Select CONFIG_MFD_SYSCON ...
2024-07-24Merge tag 'soundwire-6.11-rc1' of ↵Linus Torvalds16-80/+271
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire Pull soundwire updates from Vinod Koul: - Simplification across subsystem using cleanup.h - Support for debugfs to read/write commands - Few Intel and Qualcomm driver updates * tag 'soundwire-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: soundwire: debugfs: simplify with cleanup.h soundwire: cadence: simplify with cleanup.h soundwire: intel_ace2x: simplify with cleanup.h soundwire: intel_ace2x: simplify return path in hw_params soundwire: intel: simplify with cleanup.h soundwire: intel: simplify return path in hw_params soundwire: amd_init: simplify with cleanup.h soundwire: amd: simplify with cleanup.h soundwire: amd: simplify return path in hw_params soundwire: intel_auxdevice: start the bus at default frequency soundwire: intel_auxdevice: add cs42l43 codec to wake_capable_list drivers:soundwire: qcom: cleanup port maask calculations soundwire: bus: simplify by using local slave->prop soundwire: generic_bandwidth_allocation: change port_bo parameter to pointer soundwire: Intel: clarify Copyright information soundwire: intel_ace2.x: add AC timing extensions for PantherLake soundwire: bus: add stream refcount soundwire: debugfs: add interface to read/write commands
2024-07-24Merge tag 'dmaengine-6.11-rc1' of ↵Linus Torvalds46-282/+2492
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine Pull dmaengine updates from Vinod Koul: "New support: - New dmaengine_prep_peripheral_dma_vec() to support transfers using dma vectors and documentation and user in AXI dma - STMicro STM32 DMA3 support and new capabilities of cyclic dma Updates: - Yaml conversion for Freescale imx dma and qdma bindings, sprd sc9860 dma binding - Altera msgdma updates for descriptor management" * tag 'dmaengine-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: (35 commits) dt-bindings: fsl-qdma: fix interrupts 'if' check logic dt-bindings: dma: sprd,sc9860-dma: convert to YAML dmaengine: fsl-dpaa2-qdma: add missing MODULE_DESCRIPTION() macro dmaengine: ti: add missing MODULE_DESCRIPTION() macros dmaengine: ti: cppi41: add missing MODULE_DESCRIPTION() macro dmaengine: virt-dma: add missing MODULE_DESCRIPTION() macro dmaengine: ti: k3-udma: Fix BCHAN count with UHC and HC channels dmaengine: sh: rz-dmac: Fix lockdep assert warning dmaengine: qcom: gpi: clean up the IRQ disable/enable in gpi_reset_chan() dmaengine: fsl-edma: change the memory access from local into remote mode in i.MX 8QM dmaengine: qcom: gpi: remove unused struct 'reg_info' dmaengine: moxart-dma: remove unused struct 'moxart_filter_data' dt-bindings: fsl-qdma: Convert to yaml format dmaengine: fsl-edma: remove redundant "idle" field from fsl_chan dmaengine: fsl-edma: request per-channel IRQ only when channel is allocated dmaengine: stm32-dma3: defer channel registration to specify channel name dmaengine: add channel device name to channel registration dmaengine: stm32-dma3: improve residue granularity dmaengine: stm32-dma3: add device_pause and device_resume ops dmaengine: stm32-dma3: add DMA_MEMCPY capability ...
2024-07-24sysctl: treewide: constify the ctl_table argument of proc_handlersJoel Granados93-258/+258
const qualify the struct ctl_table argument in the proc_handler function signatures. This is a prerequisite to moving the static ctl_table structs into .rodata data which will ensure that proc_handler function pointers cannot be modified. This patch has been generated by the following coccinelle script: ``` virtual patch @r1@ identifier ctl, write, buffer, lenp, ppos; identifier func !~ "appldata_(timer|interval)_handler|sched_(rt|rr)_handler|rds_tcp_skbuf_handler|proc_sctp_do_(hmac_alg|rto_min|rto_max|udp_port|alpha_beta|auth|probe_interval)"; @@ int func( - struct ctl_table *ctl + const struct ctl_table *ctl ,int write, void *buffer, size_t *lenp, loff_t *ppos); @r2@ identifier func, ctl, write, buffer, lenp, ppos; @@ int func( - struct ctl_table *ctl + const struct ctl_table *ctl ,int write, void *buffer, size_t *lenp, loff_t *ppos) { ... } @r3@ identifier func; @@ int func( - struct ctl_table * + const struct ctl_table * ,int , void *, size_t *, loff_t *); @r4@ identifier func, ctl; @@ int func( - struct ctl_table *ctl + const struct ctl_table *ctl ,int , void *, size_t *, loff_t *); @r5@ identifier func, write, buffer, lenp, ppos; @@ int func( - struct ctl_table * + const struct ctl_table * ,int write, void *buffer, size_t *lenp, loff_t *ppos); ``` * Code formatting was adjusted in xfs_sysctl.c to comply with code conventions. The xfs_stats_clear_proc_handler, xfs_panic_mask_proc_handler and xfs_deprecated_dointvec_minmax where adjusted. * The ctl_table argument in proc_watchdog_common was const qualified. This is called from a proc_handler itself and is calling back into another proc_handler, making it necessary to change it as part of the proc_handler migration. Co-developed-by: Thomas Weißschuh <[email protected]> Signed-off-by: Thomas Weißschuh <[email protected]> Co-developed-by: Joel Granados <[email protected]> Signed-off-by: Joel Granados <[email protected]>
2024-07-24apparmor: unpack transition table if dfa is not presentGeorgia Garcia1-17/+25
Due to a bug in earlier userspaces, a transition table may be present even when the dfa is not. Commit 7572fea31e3e ("apparmor: convert fperm lookup to use accept as an index") made the verification check more rigourous regressing old userspaces with the bug. For compatibility reasons allow the orphaned transition table during unpack and discard. Fixes: 7572fea31e3e ("apparmor: convert fperm lookup to use accept as an index") Signed-off-by: Georgia Garcia <[email protected]> Signed-off-by: John Johansen <[email protected]>
2024-07-24apparmor: try to avoid refing the label in apparmor_file_openMateusz Guzik2-2/+23
If the label is not stale (which is the common case), the fact that the passed file object holds a reference can be leverged to avoid the ref/unref cycle. Doing so reduces performance impact of apparmor on parallel open() invocations. When benchmarking on a 24-core vm using will-it-scale's open1_process ("Separate file open"), the results are (ops/s): before: 6092196 after: 8309726 (+36%) Signed-off-by: Mateusz Guzik <[email protected]> Signed-off-by: John Johansen <[email protected]>
2024-07-24drm/virtio: Fix type of dma-fence context variableDmitry Osipenko1-1/+1
Type of DMA fence context is u64. Fence-waiting code uses u32 for the context variable, fix it. Fixes: e4812ab8e6b1 ("drm/virtio: Refactor and optimize job submission code path") Cc: <[email protected]> # v6.4+ Signed-off-by: Dmitry Osipenko <[email protected]> Reviewed-by: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-24apparmor: test: add MODULE_DESCRIPTION()Jeff Johnson1-0/+1
Fix the 'make W=1' warning: WARNING: modpost: missing MODULE_DESCRIPTION() in security/apparmor/apparmor_policy_unpack_test.o Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: John Johansen <[email protected]>
2024-07-24apparmor: take nosymfollow flag into accountAlexander Mikhalitsyn1-0/+2
A "nosymfollow" flag was added in commit dab741e0e02b ("Add a "nosymfollow" mount option.") While we don't need to implement any special logic on the AppArmor kernel side to handle it, we should provide user with a correct list of mount flags in audit logs. Signed-off-by: Alexander Mikhalitsyn <[email protected]> Reviewed-by: Georgia Garcia <[email protected]> Signed-off-by: John Johansen <[email protected]>
2024-07-24Merge tag 'random-6.11-rc1-for-linus' of ↵Linus Torvalds37-18/+1121
git://git.kernel.org/pub/scm/linux/kernel/git/crng/random Pull random number generator updates from Jason Donenfeld: "This adds getrandom() support to the vDSO. First, it adds a new kind of mapping to mmap(2), MAP_DROPPABLE, which lets the kernel zero out pages anytime under memory pressure, which enables allocating memory that never gets swapped to disk but also doesn't count as being mlocked. Then, the vDSO implementation of getrandom() is introduced in a generic manner and hooked into random.c. Next, this is implemented on x86. (Also, though it's not ready for this pull, somebody has begun an arm64 implementation already) Finally, two vDSO selftests are added. There are also two housekeeping cleanup commits" * tag 'random-6.11-rc1-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random: MAINTAINERS: add random.h headers to RNG subsection random: note that RNDGETPOOL was removed in 2.6.9-rc2 selftests/vDSO: add tests for vgetrandom x86: vdso: Wire up getrandom() vDSO implementation random: introduce generic vDSO getrandom() implementation mm: add MAP_DROPPABLE for designating always lazily freeable mappings
2024-07-24Merge tag 'vfs-6.11-rc1.fixes.2' of ↵Linus Torvalds24-213/+488
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: "VFS: - The new 64bit mount ids start after the old mount id, i.e., at the first non-32 bit value. However, we started counting one id too late and thus lost 4294967296 as the first valid id. Fix that. - Update a few comments on some vfs_*() creation helpers. - Move copying of the xattr name out from the locks required to start a filesystem write. - Extend the filelock lock UAF fix to the compat code as well. - Now that we added the ability to look up an inode under RCU it's possible that lockless hash lookup can find and lock an inode after it gets I_FREEING set. It then waits until inode teardown in evict() is finished. The flag however is still set after evict() has woken up all waiters. If the inode lock is taken late enough on the waiting side after hash removal and wakeup happened the waiting thread will never be woken. Before RCU based lookup this was synchronized via the inode_hash_lock. But since unhashing requires the inode lock as well we can check whether the inode is unhashed while holding inode lock even without holding inode_hash_lock. pidfd: - The nsproxy structure contains nearly all of the namespaces associated with a task. When a namespace type isn't supported nsproxy might contain a NULL pointer or always point to the initial namespace type. The logic isn't consistent. So when deriving namespace fds we need to ensure that the namespace type is supported. First, so that we don't risk dereferncing NULL pointers. The correct bigger fix would be to change all namespaces to always set a valid namespace pointer in struct nsproxy independent of whether or not it is compiled in. But that requires quite a few changes. Second, so that we don't allow deriving namespace fds when the namespace type doesn't exist and thus when they couldn't also be derived via /proc/self/ns/. - Add missing selftests for the new pidfd ioctls to derive namespace fds. This simply extends the already existing testsuite. netfs: - Fix debug logging and fix kconfig variable name so it actually works. - Fix writeback that goes both to the server and cache. The streams are only activated once a subreq is added. When a server write happens the subreq doesn't need to have finished by the time the cache write is started. If the server write has already finished by the time the cache write is about to start the cache write will operate on a folio that might already have been reused. Fix this by preactivating the cache write. - Limit cachefiles subreq size for cache writes to MAX_RW_COUNT" * tag 'vfs-6.11-rc1.fixes.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: inode: clarify what's locked vfs: Fix potential circular locking through setxattr() and removexattr() filelock: Fix fcntl/close race recovery compat path fs: use all available ids cachefiles: Set the max subreq size for cache writes to MAX_RW_COUNT netfs: Fix writeback that needs to go to both server and cache pidfs: add selftests for new namespace ioctls pidfs: handle kernels without namespaces cleanly pidfs: when time ns disabled add check for ioctl vfs: correct the comments of vfs_*() helpers vfs: handle __wait_on_freeing_inode() and evict() race netfs: Rename CONFIG_FSCACHE_DEBUG to CONFIG_NETFS_DEBUG netfs: Revert "netfs: Switch debug logging to pr_debug()"
2024-07-24selftests/hid: add test for attaching multiple time the same struct_opsBenjamin Tissoires1-0/+18
Turns out that we would en up in a bad state if we attempt to attach twice the same HID-BPF struct_ops, so have a test for it. Link: https://patch.msgid.link/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
2024-07-24HID: bpf: prevent the same struct_ops to be attached more than onceBenjamin Tissoires1-0/+5
If the struct_ops is already attached, we should bail out or we will end up in various locks and pointer issues while unregistering. Link: https://patch.msgid.link/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
2024-07-24selftests/hid: disable struct_ops auto-attachBenjamin Tissoires1-0/+8
Since commit 08ac454e258e ("libbpf: Auto-attach struct_ops BPF maps in BPF skeleton"), libbpf automatically calls bpf_map__attach_struct_ops() on every struct_ops it sees in the bpf object. The problem is that our test bpf object has many of them but only one should be manually loaded at a time, or we end up locking the syscall. Link: https://patch.msgid.link/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
2024-07-24selftests/hid: fix bpf_wq new APIBenjamin Tissoires2-2/+2
Since commit f56f4d541eab ("bpf: helpers: fix bpf_wq_set_callback_impl signature"), the API for bpf_wq changed a bit. We need to update the selftests/hid code to reflect that or the bpf program will not load. Link: https://patch.msgid.link/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]>
2024-07-24hostfs: fix folio conversionLinus Torvalds1-1/+1
Commit e3ec0fe944d2 ("hostfs: Convert hostfs_read_folio() to use a folio") simplified hostfs_read_folio(), but in the process of converting to using folios natively also mis-used the folio_zero_tail() function due to the very confusing API of that function. Very arguably it's folio_zero_tail() API itself that is buggy, since it would make more sense (and the documentation kind of implies) that the third argument would be the pointer to the beginning of the folio buffer. But no, the third argument to folio_zero_tail() is where we should start zeroing the tail (even if we already also pass in the offset separately as the second argument). So fix the hostfs caller, and we can leave any folio_zero_tail() sanity cleanup for later. Reported-and-tested-by: Maciej Żenczykowski <[email protected]> Fixes: e3ec0fe944d2 ("hostfs: Convert hostfs_read_folio() to use a folio") Link: https://lore.kernel.org/all/CANP3RGceNzwdb7w=vPf5=7BCid5HVQDmz1K5kC9JG42+HVAh_g@mail.gmail.com/ Cc: Matthew Wilcox <[email protected]> Cc: Christian Brauner <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2024-07-24ALSA: hda/realtek: cs35l41: Fixup remaining asus strix modelsLuke D. Jones1-3/+3
Adjust quirks for 0x3a20, 0x3a30, 0x3a50 to match the 0x3a60. This set has now been confirmed to work with this patch. Signed-off-by: Luke D. Jones <[email protected]> Fixes: 811dd426a9b1 ("ALSA: hda/realtek: Add quirks for Asus ROG 2024 laptops using CS35L41") Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2024-07-24ublk: fix UBLK_CMD_DEL_DEV_ASYNC handlingMing Lei1-1/+4
In ublk_ctrl_uring_cmd(), ioctl command NR should be used for matching _IOC_NR(cmd_op). Fix it by adding one private macro, and this way is clean. Fixes: 13fe8e6825e4 ("ublk: add UBLK_CMD_DEL_DEV_ASYNC") Signed-off-by: Ming Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-07-24block: fix deadlock between sd_remove & sd_releaseYang Yang1-1/+1
Our test report the following hung task: [ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds. [ 2538.459427] Call trace: [ 2538.459430] __switch_to+0x174/0x338 [ 2538.459436] __schedule+0x628/0x9c4 [ 2538.459442] schedule+0x7c/0xe8 [ 2538.459447] schedule_preempt_disabled+0x24/0x40 [ 2538.459453] __mutex_lock+0x3ec/0xf04 [ 2538.459456] __mutex_lock_slowpath+0x14/0x24 [ 2538.459459] mutex_lock+0x30/0xd8 [ 2538.459462] del_gendisk+0xdc/0x350 [ 2538.459466] sd_remove+0x30/0x60 [ 2538.459470] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459474] device_release_driver+0x18/0x28 [ 2538.459478] bus_remove_device+0x15c/0x174 [ 2538.459483] device_del+0x1d0/0x358 [ 2538.459488] __scsi_remove_device+0xa8/0x198 [ 2538.459493] scsi_forget_host+0x50/0x70 [ 2538.459497] scsi_remove_host+0x80/0x180 [ 2538.459502] usb_stor_disconnect+0x68/0xf4 [ 2538.459506] usb_unbind_interface+0xd4/0x280 [ 2538.459510] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459514] device_release_driver+0x18/0x28 [ 2538.459518] bus_remove_device+0x15c/0x174 [ 2538.459523] device_del+0x1d0/0x358 [ 2538.459528] usb_disable_device+0x84/0x194 [ 2538.459532] usb_disconnect+0xec/0x300 [ 2538.459537] hub_event+0xb80/0x1870 [ 2538.459541] process_scheduled_works+0x248/0x4dc [ 2538.459545] worker_thread+0x244/0x334 [ 2538.459549] kthread+0x114/0x1bc [ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds. [ 2538.461014] Call trace: [ 2538.461016] __switch_to+0x174/0x338 [ 2538.461021] __schedule+0x628/0x9c4 [ 2538.461025] schedule+0x7c/0xe8 [ 2538.461030] blk_queue_enter+0xc4/0x160 [ 2538.461034] blk_mq_alloc_request+0x120/0x1d4 [ 2538.461037] scsi_execute_cmd+0x7c/0x23c [ 2538.461040] ioctl_internal_command+0x5c/0x164 [ 2538.461046] scsi_set_medium_removal+0x5c/0xb0 [ 2538.461051] sd_release+0x50/0x94 [ 2538.461054] blkdev_put+0x190/0x28c [ 2538.461058] blkdev_release+0x28/0x40 [ 2538.461063] __fput+0xf8/0x2a8 [ 2538.461066] __fput_sync+0x28/0x5c [ 2538.461070] __arm64_sys_close+0x84/0xe8 [ 2538.461073] invoke_syscall+0x58/0x114 [ 2538.461078] el0_svc_common+0xac/0xe0 [ 2538.461082] do_el0_svc+0x1c/0x28 [ 2538.461087] el0_svc+0x38/0x68 [ 2538.461090] el0t_64_sync_handler+0x68/0xbc [ 2538.461093] el0t_64_sync+0x1a8/0x1ac T1: T2: sd_remove del_gendisk __blk_mark_disk_dead blk_freeze_queue_start ++q->mq_freeze_depth bdev_release mutex_lock(&disk->open_mutex) sd_release scsi_execute_cmd blk_queue_enter wait_event(!q->mq_freeze_depth) mutex_lock(&disk->open_mutex) SCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in this scenario. This is a classic ABBA deadlock. To fix the deadlock, make sure we don't try to acquire disk->open_mutex after freezing the queue. Cc: [email protected] Fixes: eec1be4c30df ("block: delete partitions later in del_gendisk") Signed-off-by: Yang Yang <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Fixes: and Cc: stable tags are missing. Otherwise this patch looks fine Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-07-24selftests/landlock: Add cred_transfer testMickaël Salaün2-0/+75
Check that keyctl(KEYCTL_SESSION_TO_PARENT) preserves the parent's restrictions. Fixes: e1199815b47b ("selftests/landlock: Add user space tests") Co-developed-by: Jann Horn <[email protected]> Signed-off-by: Jann Horn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]>
2024-07-24landlock: Don't lose track of restrictions on cred_transferJann Horn1-2/+9
When a process' cred struct is replaced, this _almost_ always invokes the cred_prepare LSM hook; but in one special case (when KEYCTL_SESSION_TO_PARENT updates the parent's credentials), the cred_transfer LSM hook is used instead. Landlock only implements the cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes all information on Landlock restrictions to be lost. This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself. Fix it by adding a cred_transfer hook that does the same thing as the existing cred_prepare hook. (Implemented by having hook_cred_prepare() call hook_cred_transfer() so that the two functions are less likely to accidentally diverge in the future.) Cc: [email protected] Fixes: 385975dca53e ("landlock: Set up the security framework and manage credentials") Signed-off-by: Jann Horn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]>
2024-07-24RISC-V: Select ACPI PPTT driversYunhui Cui1-0/+1
After adding ACPI support to populate_cache_leaves(), RISC-V can build cacheinfo through the ACPI PPTT table, thus enabling the ACPI_PPTT configuration. Signed-off-by: Yunhui Cui <[email protected]> Reviewed-by: Jeremy Linton <[email protected]> Reviewed-by: Sudeep Holla <[email protected]> Reviewed-by: Sunil V L <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-07-24riscv: cacheinfo: initialize cacheinfo's level and type from ACPI PPTTYunhui Cui1-0/+22
Before cacheinfo can be built correctly, we need to initialize level and type. Since RISC-V currently does not have a register group that describes cache-related attributes like ARM64, we cannot obtain them directly, so now we obtain cache leaves from the ACPI PPTT table (acpi_get_cache_info()) and set the cache type through split_levels. Suggested-by: Jeremy Linton <[email protected]> Suggested-by: Sudeep Holla <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Reviewed-by: Sunil V L <[email protected]> Reviewed-by: Jeremy Linton <[email protected]> Reviewed-by: Sudeep Holla <[email protected]> Signed-off-by: Yunhui Cui <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-07-24riscv: cacheinfo: remove the useless input parameter (node) of ci_leaf_init()Yunhui Cui1-7/+6
ci_leaf_init() is a declared static function. The implementation of the function body and the caller do not use the parameter (struct device_node *node) input parameter, so remove it. Fixes: 6a24915145c9 ("Revert "riscv: Set more data to cacheinfo"") Signed-off-by: Yunhui Cui <[email protected]> Reviewed-by: Jeremy Linton <[email protected]> Reviewed-by: Sudeep Holla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-07-24RISC-V: ACPI: Enable SPCR table for console output on RISC-VSia Jee Heng2-1/+12
The ACPI SPCR code has been used to enable console output for ARM64 and X86. The same code can be reused for RISC-V. Furthermore, SPCR table is mandated for headless system as outlined in the RISC-V BRS Specification, chapter 6. Signed-off-by: Sia Jee Heng <[email protected]> Reviewed-by: Sunil V L <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-07-24MAINTAINERS: make Breno the netconsole maintainerJakub Kicinski1-0/+6
netconsole has no maintainer, and Breno has been working on improving it consistently for some time. So I think we found the maintainer :) Acked-by: Paolo Abeni <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Acked-by: Breno Leitao <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-07-24MAINTAINERS: Update bonding entryJay Vosburgh1-3/+2
Update my email address, clarify support status, and delete the web site that hasn't been used in a long time. Signed-off-by: Jay Vosburgh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-07-24net: nexthop: Initialize all fields in dumped nexthopsPetr Machata1-3/+4
struct nexthop_grp contains two reserved fields that are not initialized by nla_put_nh_group(), and carry garbage. This can be observed e.g. with strace (edited for clarity): # ip nexthop add id 1 dev lo # ip nexthop add id 101 group 1 # strace -e recvmsg ip nexthop get id 101 ... recvmsg(... [{nla_len=12, nla_type=NHA_GROUP}, [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52 The fields are reserved and therefore not currently used. But as they are, they leak kernel memory, and the fact they are not just zero complicates repurposing of the fields for new ends. Initialize the full structure. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: Petr Machata <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-07-24net: stmmac: Correct byte order of perfect_matchSimon Horman4-5/+5
The perfect_match parameter of the update_vlan_hash operation is __le16, and is correctly converted from host byte-order in the lone caller, stmmac_vlan_update(). However, the implementations of this caller, dwxgmac2_update_vlan_hash() and dwxgmac2_update_vlan_hash(), both treat this parameter as host byte order, using the following pattern: u32 value = ... ... writel(value | perfect_match, ...); This is not correct because both: 1) value is host byte order; and 2) writel expects a host byte order value as it's first argument I believe that this will break on big endian systems. And I expect it has gone unnoticed by only being exercised on little endian systems. The approach taken by this patch is to update the callback, and it's caller to simply use a host byte order value. Flagged by Sparse. Compile tested only. Fixes: c7ab0b8088d7 ("net: stmmac: Fallback to VLAN Perfect filtering if HASH is not available") Signed-off-by: Simon Horman <[email protected]> Reviewed-by: Maxime Chevallier <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-07-24io_uring: align iowq and task request error handlingPavel Begunkov1-1/+1
There is a difference in how io_queue_sqe and io_wq_submit_work treat error codes they get from io_issue_sqe. The first one fails anything unknown but latter only fails when the code is negative. It doesn't make sense to have this discrepancy, align them to the io_queue_sqe behaviour. Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/c550e152bf4a290187f91a4322ddcb5d6d1f2c73.1721819383.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2024-07-24io_uring: kill REQ_F_CANCEL_SEQPavel Begunkov1-3/+0
We removed the reliance on the flag by the cancellation path and now it's unused. Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/e57afe566bbe4fefeb44daffb08900f2a4756577.1721819383.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2024-07-24io_uring: simplify io_uring_cmd returnPavel Begunkov1-1/+1
We don't have to return error code from an op handler back to core io_uring, so once io_uring_cmd() sets the results and handles errors we can juts return IOU_OK and simplify the code. Note, only valid with e0b23d9953b0c ("io_uring: optimise ltimeout for inline execution"), there was a problem with iopoll before. Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/8eae2be5b2a49236cd5f1dadbd1aa5730e9e2d4f.1721819383.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2024-07-24io_uring: fix io_match_task must_holdPavel Begunkov1-1/+1
The __must_hold annotation in io_match_task() uses a non existing parameter "req", fix it. Fixes: 6af3f48bf6156 ("io_uring: fix link traversal locking") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/3e65ee7709e96507cef3d93291746f2c489f2307.1721819383.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2024-07-24io_uring: don't allow netpolling with SETUP_IOPOLLPavel Begunkov1-0/+2
IORING_SETUP_IOPOLL rings don't have any netpoll handling, let's fail attempts to register netpolling in this case, there might be people who will mix up IOPOLL and netpoll. Cc: [email protected] Fixes: ef1186c1a875b ("io_uring: add register/unregister napi function") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/1e7553aee0a8ae4edec6742cd6dd0c1e6914fba8.1721819383.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2024-07-24io_uring: tighten task exit cancellationsPavel Begunkov1-1/+4
io_uring_cancel_generic() should retry if any state changes like a request is completed, however in case of a task exit it only goes for another loop and avoids schedule() if any tracked (i.e. REQ_F_INFLIGHT) request got completed. Let's assume we have a non-tracked request executing in iowq and a tracked request linked to it. Let's also assume io_uring_cancel_generic() fails to find and cancel the request, i.e. via io_run_local_work(), which may happen as io-wq has gaps. Next, the request logically completes, io-wq still hold a ref but queues it for completion via tw, which happens in io_uring_try_cancel_requests(). After, right before prepare_to_wait() io-wq puts the request, grabs the linked one and tries executes it, e.g. arms polling. Finally the cancellation loop calls prepare_to_wait(), there are no tw to run, no tracked request was completed, so the tctx_inflight() check passes and the task is put to indefinite sleep. Cc: [email protected] Fixes: 3f48cf18f886c ("io_uring: unify files and task cancel") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/acac7311f4e02ce3c43293f8f1fda9c705d158f1.1721819383.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2024-07-24riscv: boot: remove duplicated targets lineJisheng Zhang1-1/+0
The "targets:" is duplicated in another line, remove the one with less targets. Signed-off-by: Jisheng Zhang <[email protected]> Reviewed-by: Emil Renner Berthing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-07-24trace: riscv: Remove deprecated kprobe on ftrace supportJinjie Ruan3-67/+0
Since commit 7caa9765465f60 ("ftrace: riscv: move from REGS to ARGS"), kprobe on ftrace is not supported by riscv, because riscv's support for FTRACE_WITH_REGS has been replaced with support for FTRACE_WITH_ARGS, and KPROBES_ON_FTRACE will be supplanted by FPROBES. So remove the deprecated kprobe on ftrace support, which is misunderstood. Signed-off-by: Jinjie Ruan <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
2024-07-24selftests: forwarding: skip if kernel not support setting bridge fdb ↵Hangbin Liu1-0/+18
learning limit If the testing kernel doesn't support setting fdb_max_learned or show fdb_n_learned, just skip it. Or we will get errors like ./bridge_fdb_learning_limit.sh: line 218: [: null: integer expression expected ./bridge_fdb_learning_limit.sh: line 225: [: null: integer expression expected Fixes: 6f84090333bb ("selftests: forwarding: bridge_fdb_learning_limit: Add a new selftest") Signed-off-by: Hangbin Liu <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Reviewed-by: Johannes Nixdorf <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-07-24tipc: Return non-zero value from tipc_udp_addr2str() on errorShigeru Yoshida1-1/+4
tipc_udp_addr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP media address. Fixes: d0f91938bede ("tipc: add ip/udp media type") Signed-off-by: Shigeru Yoshida <[email protected]> Reviewed-by: Tung Nguyen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-07-24thermal: core: Back off when polling thermal zones on errorsRafael J. Wysocki2-7/+61
Commit a8a261774466 ("thermal: core: Call monitor_thermal_zone() if zone temperature is invalid") introduced a polling mechanism by which the thermal core attampts to get a valid temperature value for thermal zones where the .get_temp() callback returns errors to start with (for example, due to initialization ordering woes). However, this polling is carried out periodically ad infinitum and every iteration of it causes a message to be printed to the kernel log which means a lot of log noise on systems where there are thermal zones that never get ready for some reason. It is also not really useful to continuously poll thermal zones that never respond. To address this, modify the thermal core to increase the delay between consecutive thermal zone temperature checks after every check that fails until it reaches a certain maximum value. At that point, the thermal zone in question will be disabled, but user space will be able to reenable it if it believes that the failure is transient. Also change the code to print messages regarding failed temperature checks to the kernel log only twice, once when the thermal zone's .get_temp() callback returns an error for the first time and once when disabling the given thermal zone. In addition, a dev_crit() message will be printed at that point if the given thermal zone contains a critical trip point to notify the system operator about the situation. Fixes: a8a261774466 ("thermal: core: Call monitor_thermal_zone() if zone temperature is invalid") Link: https://lore.kernel.org/linux-acpi/CAGnHSE=RyPK++UG0-wAtVKgeJxe0uzFYgLxm+RUOKKoQquW=Ow@mail.gmail.com/ Reported-by: Tom Yan <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-07-24ASoC: SOF: ipc4-topology: Preserve the DMA Link ID for ChainDMA on unpreparePeter Ujfalusi1-1/+7
The DMA Link ID is set to the IPC message's primary during dai_config, which is only during hw_params. During xrun handling the hw_params is not called and the DMA Link ID information will be lost. All other fields in the message expected to be 0 for re-configuration, only the DMA Link ID needs to be preserved and the in case of repeated dai_config, it is correctly updated (masked and then set). Cc: [email protected] Fixes: ca5ce0caa67f ("ASoC: SOF: ipc4/intel: Add support for chained DMA") Link: https://github.com/thesofproject/linux/issues/5116 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-07-24ASoC: SOF: ipc4-topology: Only handle dai_config with HW_PARAMS for ChainDMAPeter Ujfalusi1-2/+8
The DMA Link ID is only valid in snd_sof_dai_config_data when the dai_config is called with HW_PARAMS. The commit that this patch fixes is actually moved a code section without changing it, the same bug exists in the original code, needing different patch to kernel prior to 6.9 kernels. Cc: [email protected] Fixes: 3858464de57b ("ASoC: SOF: ipc4-topology: change chain_dma handling in dai_config") Link: https://github.com/thesofproject/linux/issues/5116 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-07-24kbuild: rpm-pkg: Fix C locale setupPetr Vorel1-1/+1
semicolon separation in LC_ALL is wrong. Either variable needs to be exported before as a separate commit or set as part of the commit in the beginning. Used second variant. This fixes broken build on user's locale setup which makes 'date' binary to produce invalid characters in rpm changelog (e.g. cs_CZ.UTF-8 'čec'): $ make binrpm-pkg GEN rpmbuild/SPECS/kernel.spec rpmbuild -bb rpmbuild/SPECS/kernel.spec --define='_topdirlinux/rpmbuild' \ --target x86_64-linux --build-in-place --noprep --define='_smp_mflags \ %{nil}' $(rpm -q rpm >/dev/null 2>&1 || echo --nodeps) Building target platforms: x86_64-linux Building for target x86_64-linux error: bad date in %changelog: St čec 24 2024 user <user@somehost> make[2]: *** [scripts/Makefile.package:71: binrpm-pkg] Error 1 make[1]: *** [linux/Makefile:1546: binrpm-pkg] Error 2 make: *** [Makefile:224: __sub-make] Error 2 Fixes: 301c10908e42 ("kbuild: rpm-pkg: introduce a simple changelog section for kernel.spec") Signed-off-by: Petr Vorel <[email protected]> Reviewed-by: Miguel Ojeda <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2024-07-24inode: clarify what's lockedChristian Brauner1-11/+11
In __wait_on_freeing_inode() we warn in case the inode_hash_lock is held but the inode is unhashed. We then release the inode_lock. So using "locked" as parameter name is confusing. Use is_inode_hash_locked as parameter name instead. Signed-off-by: Christian Brauner <[email protected]>
2024-07-24vfs: Fix potential circular locking through setxattr() and removexattr()David Howells1-43/+48
When using cachefiles, lockdep may emit something similar to the circular locking dependency notice below. The problem appears to stem from the following: (1) Cachefiles manipulates xattrs on the files in its cache when called from ->writepages(). (2) The setxattr() and removexattr() system call handlers get the name (and value) from userspace after taking the sb_writers lock, putting accesses of the vma->vm_lock and mm->mmap_lock inside of that. (3) The afs filesystem uses a per-inode lock to prevent multiple revalidation RPCs and in writeback vs truncate to prevent parallel operations from deadlocking against the server on one side and local page locks on the other. Fix this by moving the getting of the name and value in {get,remove}xattr() outside of the sb_writers lock. This also has the minor benefits that we don't need to reget these in the event of a retry and we never try to take the sb_writers lock in the event we can't pull the name and value into the kernel. Alternative approaches that might fix this include moving the dispatch of a write to the cache off to a workqueue or trying to do without the validation lock in afs. Note that this might also affect other filesystems that use netfslib and/or cachefiles. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-build2+ #956 Not tainted ------------------------------------------------------ fsstress/6050 is trying to acquire lock: ffff888138fd82f0 (mapping.invalidate_lock#3){++++}-{3:3}, at: filemap_fault+0x26e/0x8b0 but task is already holding lock: ffff888113f26d18 (&vma->vm_lock->lock){++++}-{3:3}, at: lock_vma_under_rcu+0x165/0x250 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (&vma->vm_lock->lock){++++}-{3:3}: __lock_acquire+0xaf0/0xd80 lock_acquire.part.0+0x103/0x280 down_write+0x3b/0x50 vma_start_write+0x6b/0xa0 vma_link+0xcc/0x140 insert_vm_struct+0xb7/0xf0 alloc_bprm+0x2c1/0x390 kernel_execve+0x65/0x1a0 call_usermodehelper_exec_async+0x14d/0x190 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 -> #3 (&mm->mmap_lock){++++}-{3:3}: __lock_acquire+0xaf0/0xd80 lock_acquire.part.0+0x103/0x280 __might_fault+0x7c/0xb0 strncpy_from_user+0x25/0x160 removexattr+0x7f/0x100 __do_sys_fremovexattr+0x7e/0xb0 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (sb_writers#14){.+.+}-{0:0}: __lock_acquire+0xaf0/0xd80 lock_acquire.part.0+0x103/0x280 percpu_down_read+0x3c/0x90 vfs_iocb_iter_write+0xe9/0x1d0 __cachefiles_write+0x367/0x430 cachefiles_issue_write+0x299/0x2f0 netfs_advance_write+0x117/0x140 netfs_write_folio.isra.0+0x5ca/0x6e0 netfs_writepages+0x230/0x2f0 afs_writepages+0x4d/0x70 do_writepages+0x1e8/0x3e0 filemap_fdatawrite_wbc+0x84/0xa0 __filemap_fdatawrite_range+0xa8/0xf0 file_write_and_wait_range+0x59/0x90 afs_release+0x10f/0x270 __fput+0x25f/0x3d0 __do_sys_close+0x43/0x70 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&vnode->validate_lock){++++}-{3:3}: __lock_acquire+0xaf0/0xd80 lock_acquire.part.0+0x103/0x280 down_read+0x95/0x200 afs_writepages+0x37/0x70 do_writepages+0x1e8/0x3e0 filemap_fdatawrite_wbc+0x84/0xa0 filemap_invalidate_inode+0x167/0x1e0 netfs_unbuffered_write_iter+0x1bd/0x2d0 vfs_write+0x22e/0x320 ksys_write+0xbc/0x130 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (mapping.invalidate_lock#3){++++}-{3:3}: check_noncircular+0x119/0x160 check_prev_add+0x195/0x430 __lock_acquire+0xaf0/0xd80 lock_acquire.part.0+0x103/0x280 down_read+0x95/0x200 filemap_fault+0x26e/0x8b0 __do_fault+0x57/0xd0 do_pte_missing+0x23b/0x320 __handle_mm_fault+0x2d4/0x320 handle_mm_fault+0x14f/0x260 do_user_addr_fault+0x2a2/0x500 exc_page_fault+0x71/0x90 asm_exc_page_fault+0x22/0x30 other info that might help us debug this: Chain exists of: mapping.invalidate_lock#3 --> &mm->mmap_lock --> &vma->vm_lock->lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock(&vma->vm_lock->lock); lock(&mm->mmap_lock); lock(&vma->vm_lock->lock); rlock(mapping.invalidate_lock#3); *** DEADLOCK *** 1 lock held by fsstress/6050: #0: ffff888113f26d18 (&vma->vm_lock->lock){++++}-{3:3}, at: lock_vma_under_rcu+0x165/0x250 stack backtrace: CPU: 0 PID: 6050 Comm: fsstress Not tainted 6.10.0-build2+ #956 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: <TASK> dump_stack_lvl+0x57/0x80 check_noncircular+0x119/0x160 ? queued_spin_lock_slowpath+0x4be/0x510 ? __pfx_check_noncircular+0x10/0x10 ? __pfx_queued_spin_lock_slowpath+0x10/0x10 ? mark_lock+0x47/0x160 ? init_chain_block+0x9c/0xc0 ? add_chain_block+0x84/0xf0 check_prev_add+0x195/0x430 __lock_acquire+0xaf0/0xd80 ? __pfx___lock_acquire+0x10/0x10 ? __lock_release.isra.0+0x13b/0x230 lock_acquire.part.0+0x103/0x280 ? filemap_fault+0x26e/0x8b0 ? __pfx_lock_acquire.part.0+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd7/0x120 down_read+0x95/0x200 ? filemap_fault+0x26e/0x8b0 ? __pfx_down_read+0x10/0x10 ? __filemap_get_folio+0x25/0x1a0 filemap_fault+0x26e/0x8b0 ? __pfx_filemap_fault+0x10/0x10 ? find_held_lock+0x7c/0x90 ? __pfx___lock_release.isra.0+0x10/0x10 ? __pte_offset_map+0x99/0x110 __do_fault+0x57/0xd0 do_pte_missing+0x23b/0x320 __handle_mm_fault+0x2d4/0x320 ? __pfx___handle_mm_fault+0x10/0x10 handle_mm_fault+0x14f/0x260 do_user_addr_fault+0x2a2/0x500 exc_page_fault+0x71/0x90 asm_exc_page_fault+0x22/0x30 Signed-off-by: David Howells <[email protected]> Link: https://lore.kernel.org/r/[email protected] cc: Alexander Viro <[email protected]> cc: Christian Brauner <[email protected]> cc: Jan Kara <[email protected]> cc: Jeff Layton <[email protected]> cc: Gao Xiang <[email protected]> cc: Matthew Wilcox <[email protected]> cc: [email protected] cc: [email protected] cc: [email protected] [brauner: fix minor issues] Signed-off-by: Christian Brauner <[email protected]>
2024-07-24filelock: Fix fcntl/close race recovery compat pathJann Horn1-5/+4
When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels. Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling") Cc: [email protected] Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563 Signed-off-by: Jann Horn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2024-07-24fs: use all available idsChristian Brauner1-1/+1
The counter is unconditionally incremented for each mount allocation. If we set it to 1ULL << 32 we're losing 4294967296 as the first valid non-32 bit mount id. Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Josef Bacik <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Christian Brauner <[email protected]>
2024-07-24cachefiles: Set the max subreq size for cache writes to MAX_RW_COUNTDavid Howells1-1/+1
Set the maximum size of a subrequest that writes to cachefiles to be MAX_RW_COUNT so that we don't overrun the maximum write we can make to the backing filesystem. Signed-off-by: David Howells <[email protected]> Link: https://lore.kernel.org/r/[email protected] cc: Jeff Layton <[email protected]> cc: [email protected] cc: [email protected] Signed-off-by: Christian Brauner <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.