aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-09-29nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()Pan Bian1-3/+3
In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the reference count of bh when the call to nilfs_dat_translate() fails. If the reference count hits 0 and its owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that, which may result in a use-after-free bug. This patch moves the release operation after unlocking and putting the page. NOTE: The function in question is only called in GC, and in combination with current userland tools, address translation using DAT does not occur in that function, so the code path that causes this issue will not be executed. However, it is possible to run that code path by intentionally modifying the userland GC library or by calling the GC ioctl directly. [[email protected]: NOTE added to the commit log] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: a3d93f709e89 ("nilfs2: block cache for garbage collection") Signed-off-by: Pan Bian <[email protected]> Reported-by: Ferry Meng <[email protected]> Closes: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ryusuke Konishi <[email protected]> Tested-by: Ryusuke Konishi <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-09-29mm: abstract moving to the next PFNMatthew Wilcox (Oracle)2-1/+17
In order to fix the L1TF vulnerability, x86 can invert the PTE bits for PROT_NONE VMAs, which means we cannot move from one PTE to the next by adding 1 to the PFN field of the PTE. This results in the BUG reported at [1]. Abstract advancing the PTE to the next PFN through a pte_next_pfn() function/macro. Link: https://lkml.kernel.org/r/[email protected] Fixes: bcc6cc832573 ("mm: add default definition of set_ptes()") Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Reported-by: [email protected] Closes: https://lkml.kernel.org/r/[email protected] [1] Reviewed-by: Yin Fengwei <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-09-29mm: report success more often from filemap_map_folio_range()Matthew Wilcox (Oracle)1-2/+2
Even though we had successfully mapped the relevant page, we would rarely return success from filemap_map_folio_range(). That leads to falling back from the VMA lock path to the mmap_lock path, which is a speed & scalability issue. Found by inspection. Link: https://lkml.kernel.org/r/[email protected] Fixes: 617c28ecab22 ("filemap: batch PTE mappings") Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Reviewed-by: Yin Fengwei <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-09-29fs: binfmt_elf_efpic: fix personality for ELF-FDPICGreg Ungerer1-3/+2
The elf-fdpic loader hard sets the process personality to either PER_LINUX_FDPIC for true elf-fdpic binaries or to PER_LINUX for normal ELF binaries (in this case they would be constant displacement compiled with -pie for example). The problem with that is that it will lose any other bits that may be in the ELF header personality (such as the "bug emulation" bits). On the ARM architecture the ADDR_LIMIT_32BIT flag is used to signify a normal 32bit binary - as opposed to a legacy 26bit address binary. This matters since start_thread() will set the ARM CPSR register as required based on this flag. If the elf-fdpic loader loses this bit the process will be mis-configured and crash out pretty quickly. Modify elf-fdpic loader personality setting so that it preserves the upper three bytes by using the SET_PERSONALITY macro to set it. This macro in the generic case sets PER_LINUX and preserves the upper bytes. Architectures can override this for their specific use case, and ARM does exactly this. The problem shows up quite easily running under qemu using the ARM architecture, but not necessarily on all types of real ARM hardware. If the underlying ARM processor does not support the legacy 26-bit addressing mode then everything will work as expected. Link: https://lkml.kernel.org/r/[email protected] Fixes: 1bde925d23547 ("fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries") Signed-off-by: Greg Ungerer <[email protected]> Cc: Al Viro <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Eric W. Biederman <[email protected]> Cc: Greg Ungerer <[email protected]> Cc: Kees Cook <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-09-29Merge tag '6.6-rc3-ksmbd-server-fixes' of git://git.samba.org/ksmbdLinus Torvalds3-4/+7
Pull smb server fixes from Steve French: "Two SMB3 server fixes for null pointer dereferences: - invalid SMB3 request case (fixes issue found in testing the read compound patch) - iovec error case in response processing" * tag '6.6-rc3-ksmbd-server-fixes' of git://git.samba.org/ksmbd: ksmbd: check iov vector index in ksmbd_conn_write() ksmbd: return invalid parameter error response if smb2 request is invalid
2023-09-29Merge tag 'ceph-for-6.6-rc4' of https://github.com/ceph/ceph-clientLinus Torvalds3-204/+238
Pull ceph fixes from Ilya Dryomov: "A series that fixes an involved 'double watch error' deadlock in RBD marked for stable and two cleanups" * tag 'ceph-for-6.6-rc4' of https://github.com/ceph/ceph-client: rbd: take header_rwsem in rbd_dev_refresh() only when updating rbd: decouple parent info read-in from updating rbd_dev rbd: decouple header read-in from updating rbd_dev->header rbd: move rbd_dev_refresh() definition Revert "ceph: make members in struct ceph_mds_request_args_ext a union" ceph: remove unnecessary check for NULL in parse_longname()
2023-09-29Merge tag 'xfs-6.6-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds4-20/+61
Pull xfs fix from Chandan Babu: - fix for commit 68b957f64fca ("xfs: load uncached unlinked inodes into memory on demand") which address review comments provided by Dave Chinner * tag 'xfs-6.6-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: fix reloading entire unlinked bucket lists
2023-09-29selftest/bpf: Add various selftests for program limitsDaniel Borkmann1-0/+84
Add various tests to check maximum number of supported programs being attached: # ./vmtest.sh -- ./test_progs -t tc_opts [...] ./test_progs -t tc_opts [ 1.185325] bpf_testmod: loading out-of-tree module taints kernel. [ 1.186826] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel [ 1.270123] tsc: Refined TSC clocksource calibration: 3407.988 MHz [ 1.272428] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fc932722, max_idle_ns: 440795381586 ns [ 1.276408] clocksource: Switched to clocksource tsc #252 tc_opts_after:OK #253 tc_opts_append:OK #254 tc_opts_basic:OK #255 tc_opts_before:OK #256 tc_opts_chain_classic:OK #257 tc_opts_chain_mixed:OK #258 tc_opts_delete_empty:OK #259 tc_opts_demixed:OK #260 tc_opts_detach:OK #261 tc_opts_detach_after:OK #262 tc_opts_detach_before:OK #263 tc_opts_dev_cleanup:OK #264 tc_opts_invalid:OK #265 tc_opts_max:OK <--- (new test) #266 tc_opts_mixed:OK #267 tc_opts_prepend:OK #268 tc_opts_replace:OK #269 tc_opts_revision:OK Summary: 18/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2023-09-29bpf, mprog: Fix maximum program check on mprog attachmentDaniel Borkmann1-0/+3
After Paul's recent improvement to syzkaller to improve coverage for bpf_mprog and tcx, it hit a splat that the program limit was surpassed. What happened is that the maximum number of progs got added, followed by another prog add request which adds with BPF_F_BEFORE flag relative to the last program in the array. The idx >= bpf_mprog_max() check in bpf_mprog_attach() still passes because the index is below the maximum but the maximum will be surpassed. We need to add a check upfront for insertions to catch this situation. Fixes: 053c8e1f235d ("bpf: Add generic attach/detach/query API for multi-progs") Reported-by: [email protected] Reported-by: [email protected] Reported-by: [email protected] Co-developed-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Tested-by: [email protected] Tested-by: [email protected] Link: https://github.com/google/syzkaller/pull/4207 Link: https://lore.kernel.org/bpf/[email protected]
2023-09-29PCI/PM: Mark devices disconnected if upstream PCIe link is down on resumeMika Westerberg1-1/+13
Mark Blakeney reported that when suspending system with a Thunderbolt dock connected and then unplugging the dock before resume (which is pretty normal flow with laptops), resuming takes long time. What happens is that the PCIe link from the root port to the PCIe switch inside the Thunderbolt device does not train (as expected, the link is unplugged): pcieport 0000:00:07.2: restoring config space at offset 0x24 (was 0x3bf12001, writing 0x3bf12001) pcieport 0000:00:07.0: waiting 100 ms for downstream link pcieport 0000:01:00.0: not ready 1023ms after resume; giving up However, at this point we still try to resume the devices below that unplugged link: pcieport 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible ... pcieport 0000:01:00.0: restoring config space at offset 0x38 (was 0xffffffff, writing 0x0) ... pcieport 0000:02:02.0: waiting 100 ms for downstream link, after activation And this is the link from PCIe switch downstream port to the xHCI on the dock: xhci_hcd 0000:03:00.0: not ready 65535ms after resume; giving up xhci_hcd 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible xhci_hcd 0000:03:00.0: restoring config space at offset 0x3c (was 0xffffffff, writing 0x1ff) This ends up slowing down the resume time considerably. For this reason mark these devices as disconnected if the link above them did not train properly. Fixes: e8b908146d44 ("PCI/PM: Increase wait time after resume") Link: https://lore.kernel.org/r/[email protected] Reported-by: Mark Blakeney <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217915 Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Lukas Wunner <[email protected]> Cc: [email protected] # v6.4+
2023-09-29PCI: of: Destroy changeset when adding PCI device node failsLizhi Hou1-8/+11
Previously of_pci_make_dev_node() leaked a cset if it failed to create a device node for the PCI device with of_changeset_create_node(). Destroy the cset if of_changeset_create_node() fails. Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Link: https://lore.kernel.org/r/[email protected] Reported-by: Herve Codina <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Lizhi Hou <[email protected]> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Herve Codina <[email protected]>
2023-09-29PCI: of_property: Handle interrupt parsing failuresLizhi Hou1-7/+18
of_pci_prop_intr_map() uses uninitialized addr_sz[] values if of_irq_parse_raw() fails, which leads to intermittent crashes. Clear addr_sz[] before use so we never use uninitialized elements. If no valid IRQs are parsed, don't bother adding the interrupt-map property. Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Link: https://lore.kernel.org/r/[email protected] Reported-by: Jonathan Cameron <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reported-by: Herve Codina <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Lizhi Hou <[email protected]> [bhelgaas: commit log, add similar report from Herve] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Herve Codina <[email protected]>
2023-09-29MAINTAINERS: Fix Florian Fainelli's email addressUwe Kleine-König1-1/+1
Commit 31345a0f5901 ("MAINTAINERS: Replace my email address") added 13 instances of [email protected] and one of only ...@broadcom. I didn't double check if Broadcom really owns that TLD, but git send-email doesn't accept it, so add ".com" to that one bogous(?) instance. Fixes: 31345a0f5901 ("MAINTAINERS: Replace my email address") Signed-off-by: Uwe Kleine-König <[email protected]> Acked-by: Florian Fainelli <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2023-09-29PCI: qcom: Fix IPQ8074 enumerationSricharan Ramabadhran1-3/+1
PARF_SLV_ADDR_SPACE_SIZE_2_3_3 is used by qcom_pcie_post_init_2_3_3(). This PCIe slave address space size register offset is 0x358 but was incorrectly changed to 0x16c by 39171b33f652 ("PCI: qcom: Remove PCIE20_ prefix from register definitions"). This prevented access to slave address space registers like iATU, etc., so the IPQ8074 PCIe controller was not enumerated. Revert back to the correct 0x358 offset and remove the unused PARF_SLV_ADDR_SPACE_SIZE_2_3_3. Fixes: 39171b33f652 ("PCI: qcom: Remove PCIE20_ prefix from register definitions") Link: https://lore.kernel.org/r/[email protected] Tested-by: Robert Marko <[email protected]> Signed-off-by: Sricharan Ramabadhran <[email protected]> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Cc: [email protected] # v6.4+
2023-09-29Merge tag 'ata-6.6-rc4' of ↵Linus Torvalds13-76/+378
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata Pull ATA fixes from Damien Le Moal: "A larger than usual set of fixes for 6.6-rc4 due to the unexpected number of fixes needed to address ATA disks suspend/resume issues. In more detail: - Add missing additionalProperties on child nodes to the pata-common DT bindings (Rob) - Fix handling of the REPORT SUPPORTED OPERATION CODES command to ignore reserved bits (Niklas) - Increase port multiplier soft reset timeout to accomodate slow devices and avoid issues on wakeup (Matthias) - A couple of minor code fixes to avoid compilation warnings in libata-core and libata-eh (me) - Many patches from me to address suspend/resume issues, and in particular a potential deadlock on resume due to the SCSI disk driver resume operation not being synchronized with libata EH port resume handling. This is addressed by changing the scsi disk driver disk start/stop control to allow libata to execute disk suspend (spin down) and resume (spin up) on its own during system suspend/resume. Runtime suspend/resume control remains with the SCSI disk driver. Other fixes include: - Fix libata power management request issuing to avoid races - Establish a link between ATA ports and SCSI devices to order PM operations - Fix device removal to avoid issues with driver rmmod removal - Fix synchronization of libata device rescan and SCSI disk resume operation - Remove libsas PM operations as suspend/resume is handled directly by the sas controller resume - Fix the SCSI disk driver to not issue commands to suspended disks, thus avoiding potential system lock-up on resume" * tag 'ata-6.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata: ata: libata-eh: Fix compilation warning in ata_eh_link_report() ata: libata-core: Fix compilation warning in ata_dev_config_ncq() scsi: sd: Do not issue commands to suspended disks on shutdown ata: libata-core: Do not register PM operations for SAS ports ata: libata-scsi: Fix delayed scsi_rescan_device() execution scsi: Do not attempt to rescan suspended devices ata: libata-scsi: Disable scsi device manage_system_start_stop scsi: sd: Differentiate system and runtime start/stop management ata: libata-scsi: link ata port and scsi device ata: libata-core: Fix port and device removal ata: libata-core: Fix ata_port_request_pm() locking ata: libata-sata: increase PMP SRST timeout to 10s ata: libata-scsi: ignore reserved bits for REPORT SUPPORTED OPERATION CODES dt-bindings: ata: pata-common: Add missing additionalProperties on child nodes
2023-09-29Merge tag 'block-6.6-2023-09-28' of git://git.kernel.dk/linuxLinus Torvalds2-2/+1
Pull block fixes from Jens Axboe: "Just two minor comment / documentation fixes for the block side" * tag 'block-6.6-2023-09-28' of git://git.kernel.dk/linux: block: fix kernel-doc for disk_force_media_change() block: correct stale comment in rq_qos_wait
2023-09-29Merge tag 'io_uring-6.6-2023-09-28' of git://git.kernel.dk/linuxLinus Torvalds1-1/+1
Pull io_uring fix from Jens Axboe: "A single fix going to stable for the IORING_OP_LINKAT flag handling" * tag 'io_uring-6.6-2023-09-28' of git://git.kernel.dk/linux: io_uring/fs: remove sqe->rw_flags checking from LINKAT
2023-09-29Merge tag 'slab-fixes-for-6.6-rc4' of ↵Linus Torvalds1-18/+18
git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab Pull slab fixes from Vlastimil Babka: - stable fix to prevent list corruption when destroying caches with leftover objects (Rafael Aquini) - fix for a gotcha in kmalloc_size_roundup() when calling it with too high size, discovered when recently a networking call site had to be fixed for a different issue (David Laight) * tag 'slab-fixes-for-6.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab: slab: kmalloc_size_roundup() must not return 0 for non-zero size mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy()
2023-09-29Merge tag 'drm-fixes-2023-09-29' of git://anongit.freedesktop.org/drm/drmLinus Torvalds11-32/+100
Pull drm fixes from Dave Airlie: "Regular pull, this feel suspiciously light so I expect next week might be a bit heavier? Let's see how we go. This is from a code point of view ivpu and i915 fixes. The only other patch is adding Danilo Krummrich to the nouveau maintainers, he's agreed to take on more of the roll after Ben retired. MAINTAINERS: - add Danilo for nouveau ivpu: - Add PCI ids for Arrow Lake - Fix memory corruption during IPC - Avoid dmesg flooding - 40xx: Wait for clock resource - 40xx: Fix interrupt usage - 40xx: Support caching when loading firmware i915: - Fix a panic regression on gen8_ggtt_insert_entries - Fix load issue due to reservation address in ggtt_reserve_guc_top - Fix a possible deadlock with guc busyness worker" * tag 'drm-fixes-2023-09-29' of git://anongit.freedesktop.org/drm/drm: accel/ivpu: Use cached buffers for FW loading accel/ivpu/40xx: Fix missing VPUIP interrupts accel/ivpu/40xx: Disable frequency change interrupt accel/ivpu/40xx: Ensure clock resource ownership Ack before Power-Up accel/ivpu: Don't flood dmesg with VPU ready message accel/ivpu: Do not use wait event interruptible MAINTAINERS: update nouveau maintainers i915/guc: Get runtime pm in busyness worker only if already active drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top i915: Limit the length of an sg list to the requested length accel/ivpu: Add Arrow Lake pci id
2023-09-29Merge tag 'gpio-fixes-for-v6.6-rc4' of ↵Linus Torvalds2-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix a potential spinlock deadlock in gpio-timberdale - mark the gpio-pmic-eic-sprd driver as one that can sleep * tag 'gpio-fixes-for-v6.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: pmic-eic-sprd: Add can_sleep flag for PMIC EIC chip gpio: timberdale: Fix potential deadlock on &tgpio->lock
2023-09-29Merge tag 'clk-fixes-for-linus' of ↵Linus Torvalds5-51/+54
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "A bunch of clk driver fixes for issues found recently: - Fix the binding for versaclock3 that was introduced this merge window so we know what the values are for clk consumers - Fix a 64-bit division issue in the versaclock3 driver - Avoid breakage in the versaclock3 driver by rejiggering the enums used to layout clks - Fix the parent name of a clk in the Spreadtrum ums512 clk driver - Fix a suspend/resume issue in Skyworks Si521xx clk driver where regmap restoration fails because writes are wedged - Return zero from Tegra bpmp recalc_rate() implementation when an error occurs so we don't consider an error as a large rate" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: tegra: fix error return case for recalc_rate clk: si521xx: Fix regmap write accessor clk: si521xx: Use REGCACHE_FLAT instead of NONE clk: sprd: Fix thm_parents incorrect configuration clk: vc3: Make vc3_clk_mux enum values based on vc3_clk enum values clk: vc3: Fix output clock mapping clk: vc3: Fix 64 by 64 division dt-bindings: clock: versaclock3: Add description for #clock-cells property
2023-09-29Merge tag 'for-v6.6-rc' of ↵Linus Torvalds11-19/+31
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply fixes from Sebastian Reichel: - core: fix use after free during device release - ab8500: avoid reporting multiple batteries to userspace - rk817: fix DT node resource leak - misc. small fixes, mostly for compiler warnings/errors * tag 'for-v6.6-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: power: supply: rk817: Fix node refcount leak power: supply: core: fix use after free in uevent power: supply: rt9467: Fix rt9467_run_aicl() power: supply: rk817: Add missing module alias power: supply: ucs1002: fix error code in ucs1002_get_property() power: vexpress: fix -Wvoid-pointer-to-enum-cast warning power: reset: use capital "OR" for multiple licenses in SPDX pwr-mlxbf: extend Kconfig to include gpio-mlxbf3 dependency power: supply: rt5033_charger: recognize EXTCON setting power: supply: mt6370: Fix missing error code in mt6370_chg_toggle_cfo() power: supply: ab8500: Set typing and props
2023-09-29Merge tag 'xtensa-20230928' of https://github.com/jcmvbkbc/linux-xtensaLinus Torvalds20-8/+35
Pull Xtensa fixes from Max Filippov: - fix build warnings from builds performed with W=1 * tag 'xtensa-20230928' of https://github.com/jcmvbkbc/linux-xtensa: xtensa: boot/lib: fix function prototypes xtensa: umulsidi3: fix conditional expression xtensa: boot: don't add include-dirs xtensa: iss/network: make functions static xtensa: tlb: include <asm/tlb.h> for missing prototype xtensa: hw_breakpoint: include header for missing prototype xtensa: smp: add headers for missing function prototypes irqchip: irq-xtensa-mx: include header for missing prototype xtensa: traps: add <linux/cpu.h> for function prototype xtensa: stacktrace: include <asm/ftrace.h> for prototype xtensa: signal: include headers for function prototypes xtensa: processor.h: add init_arch() prototype xtensa: ptrace: add prototypes to <asm/ptrace.h> xtensa: irq: include <asm/traps.h> xtensa: fault: include <asm/traps.h> xtensa: add default definition for XCHAL_HAVE_DIV32
2023-09-29arm64: errata: Add Cortex-A520 speculative unprivileged load workaroundRob Herring5-0/+28
Implement the workaround for ARM Cortex-A520 erratum 2966298. On an affected Cortex-A520 core, a speculatively executed unprivileged load might leak data from a privileged load via a cache side channel. The issue only exists for loads within a translation regime with the same translation (e.g. same ASID and VMID). Therefore, the issue only affects the return to EL0. The workaround is to execute a TLBI before returning to EL0 after all loads of privileged data. A non-shareable TLBI to any address is sufficient. The workaround isn't necessary if page table isolation (KPTI) is enabled, but for simplicity it will be. Page table isolation should normally be disabled for Cortex-A520 as it supports the CSV3 feature and the E0PD feature (used when KASLR is enabled). Cc: [email protected] Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2023-09-29arm64: Add Cortex-A520 CPU part definitionRob Herring1-0/+2
Add the CPU Part number for the new Arm design. Cc: [email protected] Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2023-09-29perf/arm-cmn: Fix the unhandled overflow status of counter 4 to 7Jing Zhang1-1/+1
The register por_dt_pmovsr Bits[7:0] indicates overflow from counters 7 to 0. But in arm_cmn_handle_irq(), only handled the overflow status of Bits[3:0] which results in unhandled overflow status of counters 4 to 7. So let the overflow status of DTC counters 4 to 7 to be handled. Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver") Signed-off-by: Jing Zhang <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2023-09-29bpf, sockmap: Reject sk_msg egress redirects to non-TCP socketsJakub Sitnicki1-0/+4
With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages sent from one TCP socket (s1) to actually egress from another TCP socket (s2): tcp_bpf_sendmsg(s1) // = sk_prot->sendmsg tcp_bpf_send_verdict(s1) // __SK_REDIRECT case tcp_bpf_sendmsg_redir(s2) tcp_bpf_push_locked(s2) tcp_bpf_push(s2) tcp_rate_check_app_limited(s2) // expects tcp_sock tcp_sendmsg_locked(s2) // ditto There is a hard-coded assumption in the call-chain, that the egress socket (s2) is a TCP socket. However in commit 122e6c79efe1 ("sock_map: Update sock type checks for UDP") we have enabled redirects to non-TCP sockets. This was done for the sake of BPF sk_skb programs. There was no indention to support sk_msg send-to-egress use case. As a result, attempts to send-to-egress through a non-TCP socket lead to a crash due to invalid downcast from sock to tcp_sock: BUG: kernel NULL pointer dereference, address: 000000000000002f ... Call Trace: <TASK> ? show_regs+0x60/0x70 ? __die+0x1f/0x70 ? page_fault_oops+0x80/0x160 ? do_user_addr_fault+0x2d7/0x800 ? rcu_is_watching+0x11/0x50 ? exc_page_fault+0x70/0x1c0 ? asm_exc_page_fault+0x27/0x30 ? tcp_tso_segs+0x14/0xa0 tcp_write_xmit+0x67/0xce0 __tcp_push_pending_frames+0x32/0xf0 tcp_push+0x107/0x140 tcp_sendmsg_locked+0x99f/0xbb0 tcp_bpf_push+0x19d/0x3a0 tcp_bpf_sendmsg_redir+0x55/0xd0 tcp_bpf_send_verdict+0x407/0x550 tcp_bpf_sendmsg+0x1a1/0x390 inet_sendmsg+0x6a/0x70 sock_sendmsg+0x9d/0xc0 ? sockfd_lookup_light+0x12/0x80 __sys_sendto+0x10e/0x160 ? syscall_enter_from_user_mode+0x20/0x60 ? __this_cpu_preempt_check+0x13/0x20 ? lockdep_hardirqs_on+0x82/0x110 __x64_sys_sendto+0x1f/0x30 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg program to prevent the crash. When attempted, user will receive an EACCES error from send/sendto/sendmsg() syscall. Fixes: 122e6c79efe1 ("sock_map: Update sock type checks for UDP") Signed-off-by: Jakub Sitnicki <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2023-09-29bpf, sockmap: Add tests for MSG_F_PEEKJohn Fastabend1-0/+51
Test that we can read with MSG_F_PEEK and then still get correct number of available bytes through FIONREAD. The recv() (without PEEK) then returns the bytes as expected. The recv() always worked though because it was just the available byte reporting that was broke before latest fixes. Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2023-09-29bpf, sockmap: Do not inc copied_seq when PEEK flag setJohn Fastabend1-1/+3
When data is peek'd off the receive queue we shouldn't considered it copied from tcp_sock side. When we increment copied_seq this will confuse tcp_data_ready() because copied_seq can be arbitrarily increased. From application side it results in poll() operations not waking up when expected. Notice tcp stack without BPF recvmsg programs also does not increment copied_seq. We broke this when we moved copied_seq into recvmsg to only update when actual copy was happening. But, it wasn't working correctly either before because the tcp_data_ready() tried to use the copied_seq value to see if data was read by user yet. See fixes tags. Fixes: e5c6de5fa0258 ("bpf, sockmap: Incorrectly handling copied_seq") Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2023-09-29bpf: tcp_read_skb needs to pop skb regardless of seqJohn Fastabend1-8/+2
Before fix e5c6de5fa0258 tcp_read_skb() would increment the tp->copied-seq value. This (as described in the commit) would cause an error for apps because once that is incremented the application might believe there is no data to be read. Then some apps would stall or abort believing no data is available. However, the fix is incomplete because it introduces another issue in the skb dequeue. The loop does tcp_recv_skb() in a while loop to consume as many skbs as possible. The problem is the call is ... tcp_recv_skb(sk, seq, &offset) ... where 'seq' is: u32 seq = tp->copied_seq; Now we can hit a case where we've yet incremented copied_seq from BPF side, but then tcp_recv_skb() fails this test ... if (offset < skb->len || (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)) ... so that instead of returning the skb we call tcp_eat_recv_skb() which frees the skb. This is because the routine believes the SKB has been collapsed per comment: /* This looks weird, but this can happen if TCP collapsing * splitted a fat GRO packet, while we released socket lock * in skb_splice_bits() */ This can't happen here we've unlinked the full SKB and orphaned it. Anyways it would confuse any BPF programs if the data were suddenly moved underneath it. To fix this situation do simpler operation and just skb_peek() the data of the queue followed by the unlink. It shouldn't need to check this condition and tcp_read_skb() reads entire skbs so there is no need to handle the 'offset!=0' case as we would see in tcp_read_sock(). Fixes: e5c6de5fa0258 ("bpf, sockmap: Incorrectly handling copied_seq") Fixes: 04919bed948dc ("tcp: Introduce tcp_read_skb()") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2023-09-29ASoC: core: Do not call link_exit() on uninitialized rtd objectsAmadeusz Sławiński2-5/+17
On init we have sequence: for_each_card_prelinks(card, i, dai_link) { ret = snd_soc_add_pcm_runtime(card, dai_link); ret = init_some_other_things(...); if (ret) goto probe_end: for_each_card_rtds(card, rtd) { ret = soc_init_pcm_runtime(card, rtd); probe_end: while on exit: for_each_card_rtds(card, rtd) snd_soc_link_exit(rtd); If init_some_other_things() step fails due to error we end up with not fully setup rtds and try to call snd_soc_link_exit on them, which depending on contents on .link_exit handler, can end up dereferencing NULL pointer. Reviewed-by: Cezary Rojewski <[email protected]> Signed-off-by: Amadeusz Sławiński <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-09-29ASoC: core: Print component name when printing logAmadeusz Sławiński1-2/+2
When printing log related to component it is useful to know, to which component it applies to. Reviewed-by: Cezary Rojewski <[email protected]> Signed-off-by: Amadeusz Sławiński <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2023-09-29io_uring/fs: remove sqe->rw_flags checking from LINKATJens Axboe1-1/+1
This is unionized with the actual link flags, so they can of course be set and they will be evaluated further down. If not we fail any LINKAT that has to set option flags. Fixes: cf30da90bc3a ("io_uring: add support for IORING_OP_LINKAT") Cc: [email protected] Reported-by: Thomas Leonard <[email protected]> Link: https://github.com/axboe/liburing/issues/955 Signed-off-by: Jens Axboe <[email protected]>
2023-09-29Merge tag 'drm-intel-fixes-2023-09-28' of ↵Dave Airlie3-13/+59
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix a panic regression on gen8_ggtt_insert_entries (Matthew Wilcox) - Fix load issue due to reservation address in ggtt_reserve_guc_top (Javier Pello) - Fix a possible deadlock with guc busyness worker (Umesh) Signed-off-by: Dave Airlie <[email protected]> From: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-09-28x86/sgx: Resolves SECS reclaim vs. page fault for EAUG raceHaitao Huang1-5/+25
The SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an enclave and set secs.epc_page to NULL. The SECS page is used for EAUG and ELDU in the SGX page fault handler. However, the NULL check for secs.epc_page is only done for ELDU, not EAUG before being used. Fix this by doing the same NULL check and reloading of the SECS page as needed for both EAUG and ELDU. The SECS page holds global enclave metadata. It can only be reclaimed when there are no other enclave pages remaining. At that point, virtually nothing can be done with the enclave until the SECS page is paged back in. An enclave can not run nor generate page faults without a resident SECS page. But it is still possible for a #PF for a non-SECS page to race with paging out the SECS page: when the last resident non-SECS page A triggers a #PF in a non-resident page B, and then page A and the SECS both are paged out before the #PF on B is handled. Hitting this bug requires that race triggered with a #PF for EAUG. Following is a trace when it happens. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:sgx_encl_eaug_page+0xc7/0x210 Call Trace: ? __kmem_cache_alloc_node+0x16a/0x440 ? xa_load+0x6e/0xa0 sgx_vma_fault+0x119/0x230 __do_fault+0x36/0x140 do_fault+0x12f/0x400 __handle_mm_fault+0x728/0x1110 handle_mm_fault+0x105/0x310 do_user_addr_fault+0x1ee/0x750 ? __this_cpu_preempt_check+0x13/0x20 exc_page_fault+0x76/0x180 asm_exc_page_fault+0x27/0x30 Fixes: 5a90d2c3f5ef ("x86/sgx: Support adding of pages to an initialized enclave") Signed-off-by: Haitao Huang <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Reviewed-by: Kai Huang <[email protected]> Acked-by: Reinette Chatre <[email protected]> Cc:[email protected] Link: https://lore.kernel.org/all/20230728051024.33063-1-haitao.huang%40linux.intel.com
2023-09-29Merge tag 'drm-misc-fixes-2023-09-28' of ↵Dave Airlie7-19/+40
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Short summary of fixes pull: * ivpu: * Add PCI ids for Arrow Lake * Fix memory corruption during IPC * Avoid dmesg flooding * 40xx: Wait for clock resource * 40xx: Fix interrupt usage * 40xx: Support caching when loading firmware Signed-off-by: Dave Airlie <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230928081208.GA7881@linux-uq9g
2023-09-28Merge tag 'irqchip-fixes-6.6-1' of ↵Thomas Gleixner4-22/+56
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip fixes from Marc Zygnier: - Fix QC PDC v3.2 support by working around broken firmware tables - Fix rzg2l-irqc missing #interrupt-cells description in the DT binding - Fix rzg2l-irqc interrupt masking Link: https://lore.kernel.org/lkml/[email protected]
2023-09-28sched/rt: Fix live lock between select_fallback_rq() and RT pushJoel Fernandes (Google)1-0/+1
During RCU-boost testing with the TREE03 rcutorture config, I found that after a few hours, the machine locks up. On tracing, I found that there is a live lock happening between 2 CPUs. One CPU has an RT task running, while another CPU is being offlined which also has an RT task running. During this offlining, all threads are migrated. The migration thread is repeatedly scheduled to migrate actively running tasks on the CPU being offlined. This results in a live lock because select_fallback_rq() keeps picking the CPU that an RT task is already running on only to get pushed back to the CPU being offlined. It is anyway pointless to pick CPUs for pushing tasks to if they are being offlined only to get migrated away to somewhere else. This could also add unwanted latency to this task. Fix these issues by not selecting CPUs in RT if they are not 'active' for scheduling, using the cpu_active_mask. Other parts in core.c already use cpu_active_mask to prevent tasks from being put on CPUs going offline. With this fix I ran the tests for days and could not reproduce the hang. Without the patch, I hit it in a few hours. Signed-off-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: Paul E. McKenney <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
2023-09-28fs/smb/client: Reset password pointer to NULLQuang Le1-0/+1
Forget to reset ctx->password to NULL will lead to bug like double free Cc: [email protected] Cc: Willy Tarreau <[email protected]> Reviewed-by: Namjae Jeon <[email protected]> Signed-off-by: Quang Le <[email protected]> Signed-off-by: Steve French <[email protected]>
2023-09-28Merge tag 'spi-fix-v6.6-rc3' of ↵Linus Torvalds3-2/+8
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A small set of device specific fixes, the most major one is for the GXP driver which would probably have been confusing some callers with returning the length rather than 0 on successful writes" * tag 'spi-fix-v6.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: spi-gxp: BUG: Correct spi write return value dt-bindings: spi: fsl-imx-cspi: Document missing entries spi: cs42l43: Remove spurious pm_runtime_disable
2023-09-28Merge tag 'loongarch-fixes-6.6-2' of ↵Linus Torvalds3-2/+31
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch fixes from Huacai Chen: "Fix high_memory calculation and module loader errors with latest binutils" * tag 'loongarch-fixes-6.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: LoongArch: Add support for 64_PCREL relocation type LoongArch: Add support for 32_PCREL relocation type LoongArch: Define relocation types for ABI v2.10 LoongArch: numa: Fix high_memory calculation
2023-09-28Merge tag 'mips-fixes_6.6_1' of ↵Linus Torvalds3-0/+14
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux Pull MIPS fix from Thomas Bogendoerfer: - fix Alchemy build with MMC support disabled * tag 'mips-fixes_6.6_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: Alchemy: only build mmc support helpers if au1xmmc is enabled
2023-09-28iomap: Spelling s/preceeding/preceding/gGeert Uytterhoeven1-1/+1
Fix a misspelling of "preceding". Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Bill O'Donnell <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2023-09-28nfs: decrement nrequests counter before releasing the reqJeff Layton1-1/+1
I hit this panic in testing: [ 6235.500016] run fstests generic/464 at 2023-09-18 22:51:24 [ 6288.410761] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 6288.412174] #PF: supervisor read access in kernel mode [ 6288.413160] #PF: error_code(0x0000) - not-present page [ 6288.413992] PGD 0 P4D 0 [ 6288.414603] Oops: 0000 [#1] PREEMPT SMP PTI [ 6288.415419] CPU: 0 PID: 340798 Comm: kworker/u18:8 Not tainted 6.6.0-rc1-gdcf620ceebac #95 [ 6288.416538] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 [ 6288.417701] Workqueue: nfsiod rpc_async_release [sunrpc] [ 6288.418676] RIP: 0010:nfs_inode_remove_request+0xc8/0x150 [nfs] [ 6288.419836] Code: ff ff 48 8b 43 38 48 8b 7b 10 a8 04 74 5b 48 85 ff 74 56 48 8b 07 a9 00 00 08 00 74 58 48 8b 07 f6 c4 10 74 50 e8 c8 44 b3 d5 <48> 8b 00 f0 48 ff 88 30 ff ff ff 5b 5d 41 5c c3 cc cc cc cc 48 8b [ 6288.422389] RSP: 0018:ffffbd618353bda8 EFLAGS: 00010246 [ 6288.423234] RAX: 0000000000000000 RBX: ffff9a29f9a25280 RCX: 0000000000000000 [ 6288.424351] RDX: ffff9a29f9a252b4 RSI: 000000000000000b RDI: ffffef41448e3840 [ 6288.425345] RBP: ffffef41448e3840 R08: 0000000000000038 R09: ffffffffffffffff [ 6288.426334] R10: 0000000000033f80 R11: ffff9a2a7fffa000 R12: ffff9a29093f98c4 [ 6288.427353] R13: 0000000000000000 R14: ffff9a29230f62e0 R15: ffff9a29230f62d0 [ 6288.428358] FS: 0000000000000000(0000) GS:ffff9a2a77c00000(0000) knlGS:0000000000000000 [ 6288.429513] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6288.430427] CR2: 0000000000000000 CR3: 0000000264748002 CR4: 0000000000770ef0 [ 6288.431553] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 6288.432715] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 6288.433698] PKRU: 55555554 [ 6288.434196] Call Trace: [ 6288.434667] <TASK> [ 6288.435132] ? __die+0x1f/0x70 [ 6288.435723] ? page_fault_oops+0x159/0x450 [ 6288.436389] ? try_to_wake_up+0x98/0x5d0 [ 6288.437044] ? do_user_addr_fault+0x65/0x660 [ 6288.437728] ? exc_page_fault+0x7a/0x180 [ 6288.438368] ? asm_exc_page_fault+0x22/0x30 [ 6288.439137] ? nfs_inode_remove_request+0xc8/0x150 [nfs] [ 6288.440112] ? nfs_inode_remove_request+0xa0/0x150 [nfs] [ 6288.440924] nfs_commit_release_pages+0x16e/0x340 [nfs] [ 6288.441700] ? __pfx_call_transmit+0x10/0x10 [sunrpc] [ 6288.442475] ? _raw_spin_lock_irqsave+0x23/0x50 [ 6288.443161] nfs_commit_release+0x15/0x40 [nfs] [ 6288.443926] rpc_free_task+0x36/0x60 [sunrpc] [ 6288.444741] rpc_async_release+0x29/0x40 [sunrpc] [ 6288.445509] process_one_work+0x171/0x340 [ 6288.446135] worker_thread+0x277/0x3a0 [ 6288.446724] ? __pfx_worker_thread+0x10/0x10 [ 6288.447376] kthread+0xf0/0x120 [ 6288.447903] ? __pfx_kthread+0x10/0x10 [ 6288.448500] ret_from_fork+0x2d/0x50 [ 6288.449078] ? __pfx_kthread+0x10/0x10 [ 6288.449665] ret_from_fork_asm+0x1b/0x30 [ 6288.450283] </TASK> [ 6288.450688] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc nls_iso8859_1 nls_cp437 vfat fat 9p netfs ext4 kvm_intel crc16 mbcache jbd2 joydev kvm xfs irqbypass virtio_net pcspkr net_failover psmouse failover 9pnet_virtio cirrus drm_shmem_helper virtio_balloon drm_kms_helper button evdev drm loop dm_mod zram zsmalloc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel sha512_ssse3 sha512_generic virtio_blk nvme aesni_intel crypto_simd cryptd nvme_core t10_pi i6300esb crc64_rocksoft_generic crc64_rocksoft crc64 virtio_pci virtio virtio_pci_legacy_dev virtio_pci_modern_dev virtio_ring serio_raw btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq autofs4 [ 6288.460211] CR2: 0000000000000000 [ 6288.460787] ---[ end trace 0000000000000000 ]--- [ 6288.461571] RIP: 0010:nfs_inode_remove_request+0xc8/0x150 [nfs] [ 6288.462500] Code: ff ff 48 8b 43 38 48 8b 7b 10 a8 04 74 5b 48 85 ff 74 56 48 8b 07 a9 00 00 08 00 74 58 48 8b 07 f6 c4 10 74 50 e8 c8 44 b3 d5 <48> 8b 00 f0 48 ff 88 30 ff ff ff 5b 5d 41 5c c3 cc cc cc cc 48 8b [ 6288.465136] RSP: 0018:ffffbd618353bda8 EFLAGS: 00010246 [ 6288.465963] RAX: 0000000000000000 RBX: ffff9a29f9a25280 RCX: 0000000000000000 [ 6288.467035] RDX: ffff9a29f9a252b4 RSI: 000000000000000b RDI: ffffef41448e3840 [ 6288.468093] RBP: ffffef41448e3840 R08: 0000000000000038 R09: ffffffffffffffff [ 6288.469121] R10: 0000000000033f80 R11: ffff9a2a7fffa000 R12: ffff9a29093f98c4 [ 6288.470109] R13: 0000000000000000 R14: ffff9a29230f62e0 R15: ffff9a29230f62d0 [ 6288.471106] FS: 0000000000000000(0000) GS:ffff9a2a77c00000(0000) knlGS:0000000000000000 [ 6288.472216] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6288.473059] CR2: 0000000000000000 CR3: 0000000264748002 CR4: 0000000000770ef0 [ 6288.474096] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 6288.475097] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 6288.476148] PKRU: 55555554 [ 6288.476665] note: kworker/u18:8[340798] exited with irqs disabled Once we've released "req", it's not safe to dereference it anymore. Decrement the nrequests counter before dropping the reference. Signed-off-by: Jeff Layton <[email protected]> Reviewed-by: Benjamin Coddington <[email protected]> Tested-by: Benjamin Coddington <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2023-09-28erofs: update documentationJingbo Xu1-3/+37
- update new features like bloom filter and DEFLATE. - add documentation for the long xattr name prefixes, which was landed upstream since v6.4. Signed-off-by: Jingbo Xu <[email protected]> Reviewed-by: Gao Xiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Gao Xiang <[email protected]>
2023-09-28NFSD: Fix zero NFSv4 READ results when RQ_SPLICE_OK is not setChuck Lever1-2/+2
nfsd4_encode_readv() uses xdr->buf->page_len as a starting point for the nfsd_iter_read() sink buffer -- page_len is going to be offset by the parts of the COMPOUND that have already been encoded into xdr->buf->pages. However, that value must be captured /before/ xdr_reserve_space_vec() advances page_len by the expected size of the read payload. Otherwise, the whole front part of the first page of the payload in the reply will be uninitialized. Mantas hit this because sec=krb5i forces RQ_SPLICE_OK off, which invokes the readv part of the nfsd4_encode_read() path. Also, older Linux NFS clients appear to send shorter READ requests for files smaller than a page, whereas newer clients just send page-sized requests and let the server send as many bytes as are in the file. Reported-by: Mantas Mikulėnas <[email protected]> Closes: https://lore.kernel.org/linux-nfs/[email protected]/ Fixes: 703d75215555 ("NFSD: Hoist rq_vec preparation into nfsd_read() [step two]") Signed-off-by: Chuck Lever <[email protected]>
2023-09-28ata: libata-eh: Fix compilation warning in ata_eh_link_report()Damien Le Moal1-1/+1
The 6 bytes length of the tries_buf string in ata_eh_link_report() is too short and results in a gcc compilation warning with W-!: drivers/ata/libata-eh.c: In function ‘ata_eh_link_report’: drivers/ata/libata-eh.c:2371:59: warning: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 4 [-Wformat-truncation=] 2371 | snprintf(tries_buf, sizeof(tries_buf), " t%d", | ^~ drivers/ata/libata-eh.c:2371:56: note: directive argument in the range [-2147483648, 4] 2371 | snprintf(tries_buf, sizeof(tries_buf), " t%d", | ^~~~~~ drivers/ata/libata-eh.c:2371:17: note: ‘snprintf’ output between 4 and 14 bytes into a destination of size 6 2371 | snprintf(tries_buf, sizeof(tries_buf), " t%d", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2372 | ap->eh_tries); | ~~~~~~~~~~~~~ Avoid this warning by increasing the string size to 16B. Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]>
2023-09-28ata: libata-core: Fix compilation warning in ata_dev_config_ncq()Damien Le Moal1-1/+1
The 24 bytes length allocated to the ncq_desc string in ata_dev_config_lba() for ata_dev_config_ncq() to use is too short, causing the following gcc compilation warnings when compiling with W=1: drivers/ata/libata-core.c: In function ‘ata_dev_configure’: drivers/ata/libata-core.c:2378:56: warning: ‘%d’ directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 11 [-Wformat-truncation=] 2378 | snprintf(desc, desc_sz, "NCQ (depth %d/%d)%s", hdepth, | ^~ In function ‘ata_dev_config_ncq’, inlined from ‘ata_dev_config_lba’ at drivers/ata/libata-core.c:2649:8, inlined from ‘ata_dev_configure’ at drivers/ata/libata-core.c:2952:9: drivers/ata/libata-core.c:2378:41: note: directive argument in the range [1, 32] 2378 | snprintf(desc, desc_sz, "NCQ (depth %d/%d)%s", hdepth, | ^~~~~~~~~~~~~~~~~~~~~ drivers/ata/libata-core.c:2378:17: note: ‘snprintf’ output between 16 and 31 bytes into a destination of size 24 2378 | snprintf(desc, desc_sz, "NCQ (depth %d/%d)%s", hdepth, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2379 | ddepth, aa_desc); | ~~~~~~~~~~~~~~~~ Avoid these warnings and the potential truncation by changing the size of the ncq_desc string to 32 characters. Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]>
2023-09-28scsi: sd: Do not issue commands to suspended disks on shutdownDamien Le Moal2-4/+14
If an error occurs when resuming a host adapter before the devices attached to the adapter are resumed, the adapter low level driver may remove the scsi host, resulting in a call to sd_remove() for the disks of the host. This in turn results in a call to sd_shutdown() which will issue a synchronize cache command and a start stop unit command to spindown the disk. sd_shutdown() issues the commands only if the device is not already runtime suspended but does not check the power state for system-wide suspend/resume. That is, the commands may be issued with the device in a suspended state, which causes PM resume to hang, forcing a reset of the machine to recover. Fix this by tracking the suspended state of a disk by introducing the suspended boolean field in the scsi_disk structure. This flag is set to true when the disk is suspended is sd_suspend_common() and resumed with sd_resume(). When suspended is true, sd_shutdown() is not executed from sd_remove(). Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]>
2023-09-28ata: libata-core: Do not register PM operations for SAS portsDamien Le Moal3-2/+11
libsas does its own domain based power management of ports. For such ports, libata should not use a device type defining power management operations as executing these operations for suspend/resume in addition to libsas calls to ata_sas_port_suspend() and ata_sas_port_resume() is not necessary (and likely dangerous to do, even though problems are not seen currently). Introduce the new ata_port_sas_type device_type for ports managed by libsas. This new device type is used in ata_tport_add() and is defined without power management operations. Fixes: 2fcbdcb4c802 ("[SCSI] libata: export ata_port suspend/resume infrastructure for sas") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Tested-by: Chia-Lin Kao (AceLan) <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Reviewed-by: John Garry <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.