| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The logic in __efi_memmap_init() is shared between two different
execution flows:
- mapping the EFI memory map early or late into the kernel VA space, so
that its entries can be accessed;
- the x86 specific cloning of the EFI memory map in order to insert new
entries that are created as a result of making a memory reservation
via a call to efi_mem_reserve().
In the former case, the underlying memory containing the kernel's view
of the EFI memory map (which may be heavily modified by the kernel
itself on x86) is not modified at all, and the only thing that changes
is the virtual mapping of this memory, which is different between early
and late boot.
In the latter case, an entirely new allocation is created that carries a
new, updated version of the kernel's view of the EFI memory map. When
installing this new version, the old version will no longer be
referenced, and if the memory was allocated by the kernel, it will leak
unless it gets freed.
The logic that implements this freeing currently lives on the code path
that is shared between these two use cases, but it should only apply to
the latter. So move it to the correct spot.
While at it, drop the dummy definition for non-x86 architectures, as
that is no longer needed.
Cc: <[email protected]>
Fixes: f0ef6523475f ("efi: Fix efi_memmap_alloc() leaks")
Tested-by: Ashish Kalra <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Ard Biesheuvel <[email protected]>
|
|
EFI runtime services are remapped into the lower 1 GiB of virtual
address space at boot, so they are guaranteed to be able to co-exist
with the kernel virtual mappings without the need to allocate space for
them in the kernel's vmalloc region, which is rather small.
This means those mappings are covered by TTBR0 when LPAE PAN is enabled,
and so 'user' access must be enabled while such calls are in progress.
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
|
|
We cannot use /delete-node/ directive to delete a node in a DT
overlay. The node won't be deleted effectively. Instead, set
the node's status property to "disabled" to achieve something
similar.
Fixes: eeb403df953f ("ARM: dts: imx53-qsb: add support for the HDMI expander")
Signed-off-by: Liu Ying <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
The IMX8MP_CLK_CLKOUT2 supplies the TC9595 bridge with 13 MHz reference
clock. The IMX8MP_CLK_CLKOUT2 is supplied from IMX8MP_AUDIO_PLL2_OUT.
The IMX8MP_CLK_CLKOUT2 operates only as a power-of-two divider, and the
current 156 MHz is not power-of-two divisible to achieve 13 MHz.
To achieve 13 MHz output from IMX8MP_CLK_CLKOUT2, set IMX8MP_AUDIO_PLL2_OUT
to 208 MHz, because 208 MHz / 16 = 13 MHz.
Fixes: 20d0b83e712b ("arm64: dts: imx8mp: Add TC9595 bridge on DH electronics i.MX8M Plus DHCOM")
Signed-off-by: Marek Vasut <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
|
|
The bus reset event occurs in the bus managed by one of 1394 OHCI
controller in Linux system, however the existing tracepoints events has
the lack of data about it to distinguish the issued hardware from the
others.
This commit adds card_index member into event structure to store the index
of host controller in use, and prints it.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Sakamoto <[email protected]>
|
|
bus_reset_arrange_template
The asynchronous transmission of phy packet is initiated on one of 1394
OHCI controller, however the existing tracepoints events has the lack of
data about it.
This commit adds card_index member into event structure to store the index
of host controller in use, and prints it.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Sakamoto <[email protected]>
|
|
The asynchronous transmission of phy packet is initiated on one of 1394
OHCI controller, however the existing tracepoints events has the lack of
data about it.
This commit adds card_index member into event structure to store the index
of host controller in use, and prints it.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Sakamoto <[email protected]>
|
|
event
The asynchronous transmission of phy packet is initiated on one of 1394
OHCI controller, however the existing tracepoints events has the lack of
data about it.
This commit adds card_index member into event structure to store the index
of host controller in use, and prints it.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Sakamoto <[email protected]>
|
|
event
The asynchronous transaction is initiated on one of 1394 OHCI
controller, however the existing tracepoints events has the lack of data
about it.
This commit adds card_index member into event structure to store the index
of host controller in use, and prints it.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Sakamoto <[email protected]>
|
|
async_inbound_template
The asynchronous transaction is initiated on one of 1394 OHCI controller,
however the existing tracepoints events has the lack of data about it.
This commit adds card_index member into event structure to store the index
of host controller in use, and prints it.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Sakamoto <[email protected]>
|
|
async_outbound_initiate_template
The asynchronous transaction is initiated on one of 1394 OHCI controller,
however the existing tracepoints events has the lack of data about it.
This commit adds card_index member into event structure to store the index
of host controller in use, and prints it.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Sakamoto <[email protected]>
|
|
async_outbound_complete_template
The asynchronous transaction is initiated on one of 1394 OHCI controller,
however the existing tracepoints events has the lack of data about it.
This commit adds card_index member into event structure to store the index
of host controller in use, and prints it.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Sakamoto <[email protected]>
|
|
The wiki in kernel.org is no longer updated. This commit replaces the
website URL with the latest one.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Sakamoto <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Vasily Gorbik:
- A couple of fixes for regressions resulting from the uncoupling of
physical vs virtual kernel address spaces: fix the mapping of the
kernel image using large pages; enforce alignment checks on physical
addresses before creating large pages
- Update defconfigs
* tag 's390-6.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/mm: Restore mapping of kernel image using large pages
s390/mm: Allow large pages only for aligned physical addresses
s390: Update defconfigs
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2024-06-11 (ice)
This series contains updates to ice driver only.
En-Wei Wu resolves IRQ collision during suspend.
Paul corrects 200Gbps speed being reported as unknown.
Wojciech adds retry mechanism when package download fails.
* '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
ice: implement AQ download pkg retry
ice: fix 200G link speed message log
ice: avoid IRQ collision to fix init failure on ACPI S3 resume
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Pull drm fixes from Dave Airlie:
"Weekly fixes. Seems a little quieter than usual, but still a bunch of
stuff across the board. Mostly xe, some exynos and nouveau fixes.
core:
- Werror Kconfig fix
panel:
- add orientation quirk for Aya Neo KUN
- fix runtime warning on panel/bridge release
nouveau:
- remove unused struct
- fix wq crash on cards with no display
amdgpu:
- fix bo release clear page warning
xe:
- update MAINTAINERS
- Use correct forcewake assertions
- Assert that VRAM provisioning is only done on DGFX
- Flush render caches before user-fence signalling on all engines
- Move the disable_c6 call since it was sometimes never called
exynos:
- fix regression with fallback mode
- fix EDID related memory leak
- remove redundant code
komeda:
- fix debugfs conditional compilations
- check pointer error value
renesas:
- atomic shutdown fix
mediatek:
- atomic shutdown fix"
* tag 'drm-fixes-2024-06-15' of https://gitlab.freedesktop.org/drm/kernel:
arm/komeda: Remove all CONFIG_DEBUG_FS conditional compilations
drm/xe: move disable_c6 call
drm/xe: flush engine buffers before signalling user fence on all engines
drm/xe/pf: Assert LMEM provisioning is done only on DGFX
drm/xe/xe_gt_idle: use GT forcewake domain assertion
drm/mediatek: Call drm_atomic_helper_shutdown() at shutdown time
drm: renesas: shmobile: Call drm_atomic_helper_shutdown() at shutdown time
drm/nouveau: remove unused struct 'init_exec'
drm/nouveau: don't attempt to schedule hpd_work on headless cards
drm/amdgpu: Fix the BO release clear memory warning
drm/bridge/panel: Fix runtime warning on panel bridge release
drm/komeda: check for error-valued pointer
drm: panel-orientation-quirks: Add quirk for Aya Neo KUN
drm/exynos/vidi: fix memory leak in .get_modes()
drm/exynos: dp: drop driver owner initialization
drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found
drm: have config DRM_WERROR depend on !WERROR
MAINTAINERS: Update Xe driver maintainers
MAINTAINERS: update Xe driver maintainers
|
|
Pull VFIO fixes from Alex Williamson:
"Fix long standing lockdep issue of using remap_pfn_range() from the
vfio-pci fault handler for mapping device MMIO. Commit ba168b52bf8e
("mm: use rwsem assertion macros for mmap_lock") now exposes this as a
warning forcing this to be addressed.
remap_pfn_range() was used here to efficiently map the entire vma, but
it really never should have been used in the fault handler and doesn't
handle concurrency, which introduced complex locking. We also needed
to track vmas mapping the device memory in order to zap those vmas
when the memory is disabled resulting in a vma list.
Instead of all that mess, setup an address space on the device fd
such that we can use unmap_mapping_range() for zapping to avoid the
tracking overhead and use the standard vmf_insert_pfn() to insert
mappings on fault.
For now we'll iterate the vma and opportunistically try to insert
mappings for the entire vma. This aligns with typical use cases, but
hopefully in the future we can drop the iterative approach and make
use of huge_fault instead, once vmf_insert_pfn{pud,pmd}() learn to
handle pfnmaps"
* tag 'vfio-v6.10-rc4' of https://github.com/awilliam/linux-vfio:
vfio/pci: Insert full vma on mmap'd MMIO fault
vfio/pci: Use unmap_mapping_range()
vfio: Create vfio_fs_type with inode per device
|
|
-EINVAL will interrupt the dump. The correct error to return
if we have more data to dump is -EMSGSIZE.
Discovered by doing:
for i in `seq 80`; do ip link add type veth; done
./cli.py --dbg-small-recv 5300 --spec netdev.yaml --dump dev-get >> /dev/null
[...]
nl_len = 64 (48) nl_flags = 0x0 nl_type = 19
nl_len = 20 (4) nl_flags = 0x2 nl_type = 3
error: -22
Fixes: d3d854fd6a1d ("netdev-genl: create a simple family for netdev stuff")
Reviewed-by: Amritha Nambiar <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
Daniel Borkmann says:
====================
pull-request: bpf 2024-06-14
We've added 8 non-merge commits during the last 2 day(s) which contain
a total of 9 files changed, 92 insertions(+), 11 deletions(-).
The main changes are:
1) Silence a syzkaller splat under CONFIG_DEBUG_NET=y in pskb_pull_reason()
triggered via __bpf_try_make_writable(), from Florian Westphal.
2) Fix removal of kfuncs during linking phase which then throws a kernel
build warning via resolve_btfids about unresolved symbols,
from Tony Ambardar.
3) Fix a UML x86_64 compilation failure from BPF as pcpu_hot symbol
is not available on User Mode Linux, from Maciej Żenczykowski.
4) Fix a register corruption in reg_set_min_max triggering an invariant
violation in BPF verifier, from Daniel Borkmann.
* tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
bpf: Harden __bpf_kfunc tag against linker kfunc removal
compiler_types.h: Define __retain for __attribute__((__retain__))
bpf: Avoid splat in pskb_pull_reason
bpf: fix UML x86_64 compile failure
selftests/bpf: Add test coverage for reg_set_min_max handling
bpf: Reduce stack consumption in check_stack_write_fixed_off
bpf: Fix reg_set_min_max corruption of fake_reg
MAINTAINERS: mailmap: Update Stanislav's email address
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
drm-misc-fixes for v6.10-rc4:
- Kconfig fix for WERROR.
- Add panel quirk for Aya Neo KUN
- Small bugfixes in komeda, bridge/panel, amdgpu, nouveau.
- Remove unused nouveau struct.
- Call drm_atomic_helper_shutdown for shmobile and mediatek on shutdown.
- Remove DEBUGFS ifdefs from komeda.
Signed-off-by: Dave Airlie <[email protected]>
From: Maarten Lankhorst <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Pull block fixes from Jens Axboe:
- NVMe pull request via Keith:
- Discard double free on error conditions (Chunguang)
- Target Fixes (Daniel)
- Namespace detachment regression fix (Keith)
- Fix for an issue with flush requests and queuelist reuse (Chengming)
- nbd sparse annotation fixes (Christoph)
- unmap and free bio mapped data via submitter (Anuj)
- loop discard/fallocate unsupported fix (Cyril)
- Fix for the zoned write plugging added in this release (Damien)
- sed-opal wrong address fix (Su)
* tag 'block-6.10-20240614' of git://git.kernel.dk/linux:
loop: Disable fallocate() zero and discard if not supported
nvme: fix namespace removal list
nbd: Remove __force casts
nvmet: always initialize cqe.result
nvmet-passthru: propagate status from id override functions
nvme: avoid double free special payload
block: unmap and free user mapped integrity via submitter
block: fix request.queuelist usage in flush
block: Optimize disk zone resource cleanup
block: sed-opal: avoid possible wrong address reference in read_sed_opal_key()
|
|
Pull io_uring fixes from Jens Axboe:
"Two fixes from Pavel headed to stable:
- Ensure that the task state is correct before attempting to grab a
mutex
- Split cancel sequence flag into a separate variable, as it can get
set by someone not owning the request (but holding the ctx lock)"
* tag 'io_uring-6.10-20240614' of git://git.kernel.dk/linux:
io_uring: fix cancellation overwriting req->flags
io_uring/rsrc: don't lock while !TASK_RUNNING
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Three obvious driver fixes and two core fixes.
The two core fixes are to disable Command Duration Limits by default
to fix an inconsistency in SATA and some USB devices. The other is to
change the default read size for block zero to follow the device
preference (some USB bridges preferring 16 byte commands don't have a
translation for READ(10) and thus don't scan properly)"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: mpi3mr: Fix ATA NCQ priority support
scsi: ufs: core: Quiesce request queues before checking pending cmds
scsi: core: Disable CDL by default
scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory
scsi: sd: Use READ(16) when reading block zero on large capacity disks
|
|
BPF kfuncs are often not directly referenced and may be inadvertently
removed by optimization steps during kernel builds, thus the __bpf_kfunc
tag mitigates against this removal by including the __used macro. However,
this macro alone does not prevent removal during linking, and may still
yield build warnings (e.g. on mips64el):
[...]
LD vmlinux
BTFIDS vmlinux
WARN: resolve_btfids: unresolved symbol bpf_verify_pkcs7_signature
WARN: resolve_btfids: unresolved symbol bpf_lookup_user_key
WARN: resolve_btfids: unresolved symbol bpf_lookup_system_key
WARN: resolve_btfids: unresolved symbol bpf_key_put
WARN: resolve_btfids: unresolved symbol bpf_iter_task_next
WARN: resolve_btfids: unresolved symbol bpf_iter_css_task_new
WARN: resolve_btfids: unresolved symbol bpf_get_file_xattr
WARN: resolve_btfids: unresolved symbol bpf_ct_insert_entry
WARN: resolve_btfids: unresolved symbol bpf_cgroup_release
WARN: resolve_btfids: unresolved symbol bpf_cgroup_from_id
WARN: resolve_btfids: unresolved symbol bpf_cgroup_acquire
WARN: resolve_btfids: unresolved symbol bpf_arena_free_pages
NM System.map
SORTTAB vmlinux
OBJCOPY vmlinux.32
[...]
Update the __bpf_kfunc tag to better guard against linker optimization by
including the new __retain compiler macro, which fixes the warnings above.
Verify the __retain macro with readelf by checking object flags for 'R':
$ readelf -Wa kernel/trace/bpf_trace.o
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[...]
[178] .text.bpf_key_put PROGBITS 00000000 6420 0050 00 AXR 0 0 8
[...]
Key to Flags:
[...]
R (retain), D (mbind), p (processor specific)
Fixes: 57e7c169cd6a ("bpf: Add __bpf_kfunc tag for marking kernel functions as kfuncs")
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Tony Ambardar <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Jiri Olsa <[email protected]>
Reviewed-by: Jiri Olsa <[email protected]>
Cc: Yonghong Song <[email protected]>
Closes: https://lore.kernel.org/r/[email protected]/
Link: https://lore.kernel.org/bpf/ZlmGoT9KiYLZd91S@krava/T/
Link: https://lore.kernel.org/bpf/e9c64e9b5c073dabd457ff45128aabcab7630098.1717477560.git.Tony.Ambardar@gmail.com
|
|
Some code includes the __used macro to prevent functions and data from
being optimized out. This macro implements __attribute__((__used__)),
which operates at the compiler and IR-level, and so still allows a linker
to remove objects intended to be kept.
Compilers supporting __attribute__((__retain__)) can address this gap by
setting the flag SHF_GNU_RETAIN on the section of a function/variable,
indicating to the linker the object should be retained. This attribute is
available since gcc 11, clang 13, and binutils 2.36.
Provide a __retain macro implementing __attribute__((__retain__)), whose
first user will be the '__bpf_kfunc' tag.
[ Additional remark from discussion:
Why is CONFIG_LTO_CLANG added here? The __used macro permits garbage
collection at section level, so CLANG_LTO_CLANG without
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION should not change final section
dynamics?
The conditional guard was included to ensure consistent behaviour
between __retain and other features forcing split sections. In
particular, the same guard is used in vmlinux.lds.h to merge split
sections where needed. For example, using __retain in LLVM builds
without CONFIG_LTO was failing CI tests on kernel-patches/bpf because
the kernel didn't boot properly. And in further testing, the kernel
had no issues loading BPF kfunc modules with such split sections, so
the module (partial) linking scripts were left alone. ]
Signed-off-by: Tony Ambardar <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Cc: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/bpf/ZlmGoT9KiYLZd91S@krava/T/
Link: https://lore.kernel.org/bpf/b31bca5a5e6765a0f32cc8c19b1d9cdbfaa822b5.1717477560.git.Tony.Ambardar@gmail.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull iommu fix from Joerg Roedel:
"A single patch that fixes a regression which several people reported:
- AMD-Vi: Fix regression causing panics"
* tag 'iommu-fix-v6.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/amd: Fix panic accessing amd_iommu_enable_faulting
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fix from Rafael Wysocki:
"Restore the behavior of the no_turbo sysfs attribute in the
intel_pstate driver which allowed users to make the driver start using
turbo P-states if they have been enabled on the fly by the firmware
after OS initialization (Rafael Wysocki)"
* tag 'pm-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: intel_pstate: Check turbo_is_disabled() in store_no_turbo()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"These fix a recent regression in the ACPI EC driver and make system
suspend work on multiple platforms where StorageD3Enable _DSD is
missing in the ACPI tables.
Specifics:
- Make the ACPI EC driver directly evaluate an "orphan" _REG method
under the EC device, if present, which stopped being evaluated
after the driver had started to install its EC address space
handler at the root of the ACPI namespace (Rafael Wysocki)
- Make more devices put NVMe storage devices into D3 at suspend to
work around missing StorageD3Enable _DSD in the BIOS (Mario
Limonciello)"
* tag 'acpi-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: EC: Evaluate orphan _REG under EC device
ACPI: x86: Force StorageD3Enable on more products
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control fixes from Rafael Wysocki:
"These fix three issues introduced recently, two related to defects in
ACPI tables supplied by the platform firmware and one cause by a
thermal core change that went too far:
- Prevent the thermal core from failing the registration of a cooling
device if its .get_cur_state() reports an incorrect state to start
with which may happen for fans handled through firmware-supplied
AML in ACPI tables (Rafael Wysocki)
- Make the ACPI thermal zone driver initialize all trip points with
temperature of 0 centigrade and below as invalid because such trip
point temperatures do not make sense on systems with ACPI thermal
control and they cause performance regressions due to permanent
thermal mitigations to occur (Rafael Wysocki)
- Restore passive polling management in the Step-Wise thermal
governor that uses it to ensure that all cooling devices used for
thermal mitigation will go back to their initial states eventually
(Rafael Wysocki)"
* tag 'thermal-6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: gov_step_wise: Restore passive polling management
thermal: ACPI: Invalidate trip points with temperature of 0 or below
thermal: core: Do not fail cdev registration because of invalid initial state
|
|
It is reported that commit 5a5efdaffda5 ("thermal: core: Resume thermal
zones asynchronously") causes battery data in sysfs on Thinkpad P1 Gen2
to become invalid after a resume from S3 (and it is necessary to reboot
the machine to restore correct battery data). Some investigation into
the problem indicated that it happened because, after the commit in
question, the ACPI battery PM notifier ran in parallel with
thermal_zone_device_resume() for one of the thermal zones which
apparently confused the platform firmware on the affected system.
While the exact reason for the firmware confusion remains unclear, it
is arguably not particularly relevant, and the expected behavior of the
affected system can be restored by making the thermal PM notifier run
at the lowest priority which avoids interference between work items
spawned by it and the other PM notifiers (that will run before those
work items now).
Fixes: 5a5efdaffda5 ("thermal: core: Resume thermal zones asynchronously")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218881
Reported-by: [email protected]
Tested-by: [email protected]
Cc: 6.8+ <[email protected]> # 6.8+
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
After commit 5a5efdaffda5 ("thermal: core: Resume thermal zones
asynchronously") it is theoretically possible that, if a system suspend
starts immediately after a system resume, thermal_zone_device_resume()
spawned by the thermal PM notifier for one of the thermal zones at the
end of the system resume will run after the PM thermal notifier for the
suspend-prepare action. If that happens, tz->suspended set by the latter
will be reset by the former which may lead to unexpected consequences.
To avoid that race, synchronize thermal_zone_device_resume() with the
suspend-prepare thermal PM notifier with the help of additional bool
field and completion in struct thermal_zone_device.
Note that this also ensures running __thermal_zone_device_update() at
least once for each thermal zone between system resume and the following
system suspend in case it is needed to start thermal mitigation.
Fixes: 5a5efdaffda5 ("thermal: core: Resume thermal zones asynchronously")
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
syzkaller builds (CONFIG_DEBUG_NET=y) frequently trigger a debug
hint in pskb_may_pull.
We'd like to retain this debug check because it might hint at integer
overflows and other issues (kernel code should pull headers, not huge
value).
In bpf case, this splat isn't interesting at all: such (nonsensical)
bpf programs are typically generated by a fuzzer anyway.
Do what Eric suggested and suppress such warning.
For CONFIG_DEBUG_NET=n we don't need the extra check because
pskb_may_pull will do the right thing: return an error without the
WARN() backtrace.
Fixes: 219eee9c0d16 ("net: skbuff: add overflow debug check to pull/push helpers")
Reported-by: [email protected]
Suggested-by: Eric Dumazet <[email protected]>
Signed-off-by: Florian Westphal <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Acked-by: Daniel Borkmann <[email protected]>
Closes: https://syzkaller.appspot.com/bug?extid=0c4150bff9fff3bf023c
Link: https://lore.kernel.org/netdev/[email protected]/
Link: https://lore.kernel.org/bpf/[email protected]
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
Various fixes:
* cfg80211: wext scan
* mac80211: monitor regression, scan counted_by, offload
* iwlwifi: locking, 6 GHz scan, remain-on-channel
* tag 'wireless-2024-06-14' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
wifi: mac80211: fix monitor channel with chanctx emulation
wifi: mac80211: Avoid address calculations via out of bounds array indexing
wifi: mac80211: Recalc offload when monitor stop
wifi: iwlwifi: scan: correctly check if PSC listen period is needed
wifi: iwlwifi: mvm: fix ROC version check
wifi: iwlwifi: mvm: unlock mvm mutex
wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
wifi: cfg80211: wext: set ssids=NULL for passive scans
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
The interface associated with the hda_component should be deactivated
before the driver is deconstructed during removal.
Fixes: 4e7914eb1dae ("ALSA: hda/tas2781: remove sound controls in unbind")
Signed-off-by: Simon Trimmer <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The interface associated with the hda_component should be deactivated
before the driver is deconstructed during removal.
Fixes: 7b2f3eb492da ("ALSA: hda: cs35l41: Add support for CS35L41 in HDA systems")
Signed-off-by: Simon Trimmer <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The interface associated with the hda_component should be deactivated
before the driver is deconstructed during removal.
Fixes: 73cfbfa9caea ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier")
Signed-off-by: Simon Trimmer <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Merge a fix for a suspend issue related to storage handling on multiple
systems based on AMD hardware:
- Make more devices put NVMe storage devices into D3 at suspend to work
around missing StorageD3Enable _DSD in the BIOS (Mario Limonciello).
* branch acpi-x86:
ACPI: x86: Force StorageD3Enable on more products
|
|
If fallcate is implemented but zero and discard operations are not
supported by the filesystem the backing file is on we continue to fill
dmesg with errors from the blk_mq_end_request() since each time we call
fallocate() on the loop device the EOPNOTSUPP error from lo_fallocate()
ends up propagated into the block layer. In the end syscall succeeds
since the blkdev_issue_zeroout() falls back to writing zeroes which
makes the errors even more misleading and confusing.
How to reproduce:
1. make sure /tmp is mounted as tmpfs
2. dd if=/dev/zero of=/tmp/disk.img bs=1M count=100
3. losetup /dev/loop0 /tmp/disk.img
4. mkfs.ext2 /dev/loop0
5. dmesg |tail
[710690.898214] operation not supported error, dev loop0, sector 204672 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 0
[710690.898279] operation not supported error, dev loop0, sector 522 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 0
[710690.898603] operation not supported error, dev loop0, sector 16906 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 0
[710690.898917] operation not supported error, dev loop0, sector 32774 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 0
[710690.899218] operation not supported error, dev loop0, sector 49674 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 0
[710690.899484] operation not supported error, dev loop0, sector 65542 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 0
[710690.899743] operation not supported error, dev loop0, sector 82442 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 0
[710690.900015] operation not supported error, dev loop0, sector 98310 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 0
[710690.900276] operation not supported error, dev loop0, sector 115210 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 0
[710690.900546] operation not supported error, dev loop0, sector 131078 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 0
This patch changes the lo_fallocate() to clear the flags for zero and
discard operations if we get EOPNOTSUPP from the backing file fallocate
callback, that way we at least stop spewing errors after the first
unsuccessful try.
CC: Jan Kara <[email protected]>
Signed-off-by: Cyril Hrubis <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>
|
|
The SCSI Removable Media Bit (RMB) should only be set for removable media,
where the device stays and the media changes, e.g. CD-ROM or floppy.
The ATA removable media device bit is obsoleted since ATA-8 ACS (2006),
but before that it was used to indicate that the device can have its media
removed (while the device stays).
Commit 8a3e33cf92c7 ("ata: ahci: find eSATA ports and flag them as
removable") introduced a change to set the RMB bit if the port has either
the eSATA bit or the hot-plug capable bit set. The reasoning was that the
author wanted his eSATA ports to get treated like a USB stick.
This is however wrong. See "20-082r23SPC-6: Removable Medium Bit
Expectations" which has since been integrated to SPC, which states that:
"""
Reports have been received that some USB Memory Stick device servers set
the removable medium (RMB) bit to one. The rub comes when the medium is
actually removed, because... The device server is removed concurrently
with the medium removal. If there is no device server, then there is no
device server that is waiting to have removable medium inserted.
Sufficient numbers of SCSI analysts see such a device:
- not as a device that supports removable medium;
but
- as a removable, hot pluggable device.
"""
The definition of the RMB bit in the SPC specification has since been
clarified to match this.
Thus, a USB stick should not have the RMB bit set (and neither shall an
eSATA nor a hot-plug capable port).
Commit dc8b4afc4a04 ("ata: ahci: don't mark HotPlugCapable Ports as
external/removable") then changed so that the RMB bit is only set for the
eSATA bit (and not for the hot-plug capable bit), because of a lot of bug
reports of SATA devices were being automounted by udisks. However,
treating eSATA and hot-plug capable ports differently is not correct.
From the AHCI 1.3.1 spec:
Hot Plug Capable Port (HPCP): When set to '1', indicates that this port's
signal and power connectors are externally accessible via a joint signal
and power connector for blindmate device hot plug.
So a hot-plug capable port is an external port, just like commit
45b96d65ec68 ("ata: ahci: a hotplug capable port is an external port")
claims.
In order to not violate the SPC specification, modify the SCSI INQUIRY
data to only set the RMB bit if the ATA device can have its media removed.
This fixes a reported problem where GNOME/udisks was automounting devices
connected to hot-plug capable ports.
Fixes: 45b96d65ec68 ("ata: ahci: a hotplug capable port is an external port")
Cc: [email protected]
Reviewed-by: Mario Limonciello <[email protected]>
Reviewed-by: Thomas Weißschuh <[email protected]>
Tested-by: Thomas Weißschuh <[email protected]>
Reported-by: Thomas Weißschuh <[email protected]>
Closes: https://lore.kernel.org/linux-ide/[email protected]/
Signed-off-by: Damien Le Moal <[email protected]>
[cassel: wrote commit message]
Signed-off-by: Niklas Cassel <[email protected]>
|
|
ovl_check_encode_origin() should return a positive number if the lower
dentry is to be encoded, zero otherwise. If there's no upper layer at all
(read-only overlay), then it obviously needs to return positive.
This was broken by commit 16aac5ad1fa9 ("ovl: support encoding
non-decodable file handles"), which didn't take the lower-only
configuration into account.
Fix by checking the no-upper-layer case up-front.
Reported-and-tested-by: Youzhong Yang <[email protected]>
Closes: https://lore.kernel.org/all/CADpNCvaBimi+zCYfRJHvCOhMih8OU0rmZkwLuh24MKKroRuT8Q@mail.gmail.com/
Fixes: 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles")
Cc: <[email protected]> # v6.6
Signed-off-by: Miklos Szeredi <[email protected]>
|
|
Roll -rc3 and current drm/fixes in.
This will also unstuck our for-next branch.
Signed-off-by: Maxime Ripard <[email protected]>
|
|
While we list the "IRQ status *and acknowledge*" registers as volatile
in the MFD description, they are missing from the writable range array,
so acknowledging any interrupts was met with an -EIO error.
This error propagates up, leading to the whole AXP717 driver failing to
probe, which is fatal to most systems using this PMIC, since most
peripherals refer one of the PMIC voltage rails.
This wasn't noticed on the initial submission, since the interrupt was
completely missing at this point, but the DTs now merged describe the
interrupt, creating the problem.
Add the five registers that hold those bits to the writable array.
This fixes the boot on the Anbernic systems using the AXP717 PMIC.
Fixes: b5bfc8ab2484 ("mfd: axp20x: Add support for AXP717 PMIC")
Reported-by: Chris Morgan <[email protected]>
Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: John Watts <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
As the comment in this function says, the code currently just clears the
CIPSO part with IPOPT_NOP, rather than removing it completely and
trimming the packet. The other cipso_v4_*_delattr() functions, however,
do the proper removal and also calipso_skbuff_delattr() makes an effort
to remove the CALIPSO options instead of replacing them with padding.
Some routers treat IPv4 packets with anything (even NOPs) in the option
header as a special case and take them through a slower processing path.
Consequently, hardening guides such as STIG recommend to configure such
routers to drop packets with non-empty IP option headers [1][2]. Thus,
users might expect NetLabel to produce packets with minimal padding (or
at least with no padding when no actual options are present).
Implement the proper option removal to address this and to be closer to
what the peer functions do.
[1] https://www.stigviewer.com/stig/juniper_router_rtr/2019-09-27/finding/V-90937
[2] https://www.stigviewer.com/stig/cisco_ios_xe_router_rtr/2021-03-26/finding/V-217001
Signed-off-by: Ondrej Mosnacek <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
As evident from the definition of ip_options_get(), the IP option
IPOPT_END is used to pad the IP option data array, not IPOPT_NOP. Yet
the loop that walks the IP options to determine the total IP options
length in cipso_v4_delopt() doesn't take IPOPT_END into account.
Fix it by recognizing the IPOPT_END value as the end of actual options.
Fixes: 014ab19a69c3 ("selinux: Set socket NetLabel based on connection endpoint")
Signed-off-by: Ondrej Mosnacek <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
After the channel context emulation, there were reports that
changing the monitor channel no longer works. This is because
those drivers don't have WANT_MONITOR_VIF, so the setting the
channel always exits out quickly.
Fix this by always allocating the virtual monitor sdata, and
simply not telling the driver about it unless it wanted to.
This way, we have an interface/sdata to bind the chanctx to,
and the emulation can work correctly.
Cc: [email protected]
Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Reported-and-tested-by: Savyasaachi Vanga <[email protected]>
Closes: https://lore.kernel.org/r/chwoymvpzwtbmzryrlitpwmta5j6mtndocxsyqvdyikqu63lon@gfds653hkknl
Link: https://msgid.link/20240612122351.b12d4a109dde.I1831a44417faaab92bea1071209abbe4efbe3fba@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
req->n_channels must be set before req->channels[] can be used.
This patch fixes one of the issues encountered in [1].
[ 83.964255] UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:364:4
[ 83.964258] index 0 is out of range for type 'struct ieee80211_channel *[]'
[...]
[ 83.964264] Call Trace:
[ 83.964267] <TASK>
[ 83.964269] dump_stack_lvl+0x3f/0xc0
[ 83.964274] __ubsan_handle_out_of_bounds+0xec/0x110
[ 83.964278] ieee80211_prep_hw_scan+0x2db/0x4b0
[ 83.964281] __ieee80211_start_scan+0x601/0x990
[ 83.964291] nl80211_trigger_scan+0x874/0x980
[ 83.964295] genl_family_rcv_msg_doit+0xe8/0x160
[ 83.964298] genl_rcv_msg+0x240/0x270
[...]
[1] https://bugzilla.kernel.org/show_bug.cgi?id=218810
Co-authored-by: Kees Cook <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Kenton Groombridge <[email protected]>
Link: https://msgid.link/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
|
|
Since the debugfs functions have no-op stubs for CONFIG_DEBUG_FS=n,
the compiler will optimize the rest away since they are no longer referenced.
The benefit of removing the conditional compilation is that the build
is actually tested for both CONFIG_DEBUG_FS configuration values.
Assuming most developers have it enabled, CONFIG_DEBUG_FS=n is not tested
much and may fail the build due to the conditional compilation.
Reported-by: k2ci <[email protected]>
Signed-off-by: pengfuyuan <[email protected]>
Acked-by: Liviu Dudau <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Liviu Dudau <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The syzbot fuzzer found that the interrupt-URB completion callback in
the cdc-wdm driver was taking too long, and the driver's immediate
resubmission of interrupt URBs with -EPROTO status combined with the
dummy-hcd emulation to cause a CPU lockup:
cdc_wdm 1-1:1.0: nonzero urb status received: -71
cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes
watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]
CPU#0 Utilization every 4s during lockup:
#1: 98% system, 0% softirq, 3% hardirq, 0% idle
#2: 98% system, 0% softirq, 3% hardirq, 0% idle
#3: 98% system, 0% softirq, 3% hardirq, 0% idle
#4: 98% system, 0% softirq, 3% hardirq, 0% idle
#5: 98% system, 1% softirq, 3% hardirq, 0% idle
Modules linked in:
irq event stamp: 73096
hardirqs last enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline]
hardirqs last enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994
hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline]
softirqs last enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582
softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588
CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Testing showed that the problem did not occur if the two error
messages -- the first two lines above -- were removed; apparently adding
material to the kernel log takes a surprisingly large amount of time.
In any case, the best approach for preventing these lockups and to
avoid spamming the log with thousands of error messages per second is
to ratelimit the two dev_err() calls. Therefore we replace them with
dev_err_ratelimited().
Signed-off-by: Alan Stern <[email protected]>
Suggested-by: Greg KH <[email protected]>
Reported-and-tested-by: [email protected]
Closes: https://lore.kernel.org/linux-usb/[email protected]/
Reported-and-tested-by: [email protected]
Closes: https://lore.kernel.org/linux-usb/[email protected]/
Fixes: 9908a32e94de ("USB: remove err() macro from usb class drivers")
Link: https://lore.kernel.org/linux-usb/[email protected]/
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Only the current owner of a request is allowed to write into req->flags.
Hence, the cancellation path should never touch it. Add a new field
instead of the flag, move it into the 3rd cache line because it should
always be initialised. poll_refs can move further as polling is an
involved process anyway.
It's a minimal patch, in the future we can and should find a better
place for it and remove now unused REQ_F_CANCEL_SEQ.
Fixes: 521223d7c229f ("io_uring/cancel: don't default to setting req->work.cancel_seq")
Cc: [email protected]
Reported-by: Li Shi <[email protected]>
Signed-off-by: Pavel Begunkov <[email protected]>
Link: https://lore.kernel.org/r/6827b129f8f0ad76fa9d1f0a773de938b240ffab.1718323430.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <[email protected]>
|
|
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
Core Changes:
- Xe Maintainers update to MAINTAINERS file.
Driver Changes:
- Use correct forcewake assertions.
- Assert that VRAM provisioning is only done on DGFX.
- Flush render caches before user-fence signalling on all engines.
- Move the disable_c6 call since it was sometimes never called.
Signed-off-by: Dave Airlie <[email protected]>
From: Thomas Hellstrom <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/ZmrXV0FoBb8M0c6J@fedora
|