The kmemleak code sometimes complains about the following leak:
unreferenced object 0xffff8000102e0000 (size 32768):
comm "swapper/0", pid 1, jiffies 4294937323 (age 71.240s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000db9a88a3>] __vmalloc_node_range+0x324/0x450
[<00000000ff8903a4>] __vmalloc_node+0x90/0xd0
[<000000001a06634f>] arm64_efi_rt_init+0x64/0xdc
[<0000000007826a8d>] do_one_initcall+0x178/0xac0
[<0000000054a87017>] do_initcalls+0x190/0x1d0
[<00000000308092d0>] kernel_init_freeable+0x2c0/0x2f0
[<000000003e7b99e0>] kernel_init+0x28/0x14c
[<000000002246af5b>] ret_from_fork+0x10/0x20
The memory object in this case is for efi_rt_stack_top and is allocated
in an initcall. So this is certainly a false positive. Mark the object
as not a leak to quash it.
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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: <stable@vger.kernel.org>
Fixes: f0ef652347 ("efi: Fix efi_memmap_alloc() leaks")
Tested-by: Ashish Kalra <Ashish.Kalra@amd.com>
Link: https://lore.kernel.org/all/36ad5079-4326-45ed-85f6-928ff76483d3@amd.com
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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 <linus.walleij@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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/20240613131440.431766-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
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/20240613131440.431766-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
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/20240613131440.431766-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
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/20240613131440.431766-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
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/20240613131440.431766-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
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/20240613131440.431766-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
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/20240613131440.431766-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
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/20240613131440.431766-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
- 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
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEE3QHqV+H2a8xAv27vjYWKoQLXFBgFAmZsyVMACgkQjYWKoQLX
FBiMBwf+Ly2mFUG3LQNPauvjhNkhH5NbkNafQTX9yzuDFn2fvQGUH+IruUosa3WI
egYWP3Z6W0nfpBGWcDleuWCcSUmUvmEiFFI4q30Ze0Q7IMm9VE14/PjSeplWwstV
pFwpZIqofvXFMbP7TYw4R6lwTe1MTtXLQSv53SMrIufeq0OnSWpWp/2dL2AC36fe
QuQCqHDuqbEvoV+3s35+xQ6OMoWcWSfG6gHgBPyQ6brkI39PlZwymdSJFanUUsl3
DCextvbUJEPSI2M5Dc0XrpOnahrN75Sh+w6FYMBcUxVMMNHdbvUXKDzQK3aPL4sQ
qNhzZJtlK545PpYEZ4TVDuU7zPQnzw==
=w9Pa
-----END PGP SIGNATURE-----
Merge tag 's390-6.10-4' of 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
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/20240613154514.1948785-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmZsvfcACgkQDHTzWXnE
hr5xDQ/+LjrK7jOp+bI4UYmu3MOieUE49iOEpKS8aNpMoKtISMca6ky/VmJPYBzQ
awN1AAEfdWNa2IqFGBZAsSCXaPuIDDqsWa8PdsXpVNKGN6AkA65TDN2a1eWehTQa
T8chEnYkQXLFmJxSpMvkpzmiEBnrwi6tvXZ0aGb0iUyyeYZm+tJj91ZW4GbJ4V8+
/sCuyCi/Nexx9O2uDAQPdqvillWF1nIO/3+2e+YwBVJO4YKMceZunKvNd661JOnq
idUml6bYvCneZh1SvIIl5gj9Qze87iCa4QR1V5jngJaSjdlBeVpm+Z/r/FdAVPd3
3Hbd1wFPlHP9UbGE/Q30RVcYUWyUu4+/w3kw46dpNbfd2UQkPy6M9UJTFwWzMrXP
FmFAA1XahPHtCqBnCOxCZI2FZGoB2Jq7tI/NRspnBQ+gcy0LiU2pNfSkevKDN/Eu
7LZeq/H2NGPuBTxe0TigsrU0ZEsqWy84tj1eTPDzWVuM8p/fogBP27vDQecLNpDG
xQw7hmwtKfI3Hd4v27NC+788SZ3PgGKR7L7QSsu30KCK5bb7cybN6TCZWPl5mXo7
3p60G5FuQX4c131iuSeoAu1Kxu5g9KFbQW1z1hR37kwfPq1bm6mzTFDZys8SSx7d
qCc3QvJHWUvCug8Mu4RU0h/ZCAMIj62rgMp5XtLqOT9i6R/4x90=
=ZzdU
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2024-06-15' of https://gitlab.freedesktop.org/drm/kernel
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
- Fix long standing lockdep issue of using remap_pfn_range() from
the vfio-pci fault handler for mapping device MMIO. Commit
ba168b52bf ("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.
(Alex Williamson)
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEQvbATlQL0amee4qQI5ubbjuwiyIFAmZsu1AbHGFsZXgud2ls
bGlhbXNvbkByZWRoYXQuY29tAAoJECObm247sIsiliUQAIYXnii7HumOdcMIPnre
twv9K4JFixpaH1bRCKd+bCoAH/7RZDRj0oSKa5OHtYiOfnlalzLAKCq84BRiUndj
cj9gYlpSlEpZl4Aa9gr2YR9ng5poQjeVq5GIzWQGZwszX2hYCk7Bz5zKbdG95zAm
qVOIFYTU+i+9D5NRMXwXEnDyKmazwuCwbmlYp4nZijMsP3/rNAy3dmDZ6ljEhIa0
p0QKvRi7L3BbTu1Zy6PXEowo1neF4d8KgViY7B1eYLsR48awmnXzMcHmvcBk14Mb
79GwripnXI2SXiGdzzqt0ODuVHs2xyV4P/Ddb6lUpZhO5KgpuxVblW5NMKSKm9ta
/12WrknWlpIKcPljWVgyDU70O9Umm3f39lUQ6Ns4e/ieS8c8GHC+5Nl5Q8PSEpqj
VYbSRuObwXSa6qzyB6O2QtNaJ8B55/bjl+FSoN4qnfccprZ7R4k96O/4hu+StZOZ
4wNaQXyB0FIakelotBy9T/ZbI4YQmhlC4FcsDXugz4wOdVUkwOVVFZ8R7jAUTNxn
Ty8RzBTSAX4alvpYhe+WFBLq3TnS+c8J7tK1q9ihfwjrEWd3gnx4M+if60XPpPHt
WxKJnvSzYvasO32AF2yTSmm3S5NlEQvQ2LTY3yfsGHfk0x/W4FEi78KcnjLZLTFk
dhf3X5qIIw8AGrLHKlgKcu61
=bSXX
-----END PGP SIGNATURE-----
Merge tag 'vfio-v6.10-rc4' of https://github.com/awilliam/linux-vfio
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 ba168b52bf
("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: d3d854fd6a ("netdev-genl: create a simple family for netdev stuff")
Reviewed-by: Amritha Nambiar <amritha.nambiar@intel.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20240613213044.3675745-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTFp0I1jqZrAX+hPRXbK58LschIgwUCZmykPwAKCRDbK58LschI
g7LOAQDVPkJ9k50/xrWIBtgvkGq1jCrMlpwEh49QYO0xoqh1IgEA+6Xje9jCIsdp
AHz9WmZ6G0EpTuDgFq50K1NVZ7MgSQE=
=zKfv
-----END PGP SIGNATURE-----
Merge tag 'for-netdev' of 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/20240614203223.26500-1-daniel@iogearbox.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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 <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/941c0552-3614-4af1-b04a-0a62c99fd7fb@linux.intel.com
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmZsY6wQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpjVoD/9emDOqfWGbYQ2DQaIyXYbWaUHteBrg1d3S
U8fRQsipHY0F3a+3eoY6Epjyt/8fq3jK4g/0/7hs+wYUtWgEXJMjl9lql7gZl4rS
3kGlk9CmwFEm5lYQAYCIDNzKr6814naGi6yYhCnstyrsSzawjr3dYP3vr9soQL3h
TvIv3PPRy6xg03mKEH+X2OSWMa4CB/85WrcKF2L/TrPD1/v3hbLZ2exfK1XX5nhl
wtM9e7fUoP0bCOx/5GKd01uJJJjrC4dhsLDRTXM1ayVrOO0jREIBi27Ho95TdzfU
MPwwWosGXgNzBCDKzZyBw1i1LFuHb+7waU/FgvpU5vXS8xaYBvm/4pWnDEGJlSAQ
8Hwiwl0uiaok9zpMCDexiWl7LdNilcS2wMxKptdpENQ9mzC+doxWqMhQLY2eRprp
eaBdLsHngS+GCiPePdZXuFMJ9Rz4/J9MEOBWmhicBDjwITLCdF6jGQ1/3tU/vQzp
wvBjc2qjOQ46uRl+HgJVNe4E2G0BZdF1b17nYEpNRatmIWMCoydZtrLNuve2ZMkG
icGP31nQe9YlgTMm/ayS2qgLD4yDFFpMeD2Ff3xXmtWZyyJ9L2UdOSUUeCZANmF8
7OVbQrHAnHi61CINGf0JHVkx1xKy/o3Z06+FEypycxlE849k8sentSHbqWsjWzMP
4jCICEwsHg==
=p7jM
-----END PGP SIGNATURE-----
Merge tag 'block-6.10-20240614' of git://git.kernel.dk/linux
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()
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmZsY78QHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgppBzEADdmuV9pgx3fGp1f+4XVdzu053z7HWFj6RU
gQ0cLAL5p0Yx5s+wYG64CC2eluYy7cPxvrfCXoMAdNnFsSSYIPDDerI3ZZ6vt5ft
m0yHJQx3V0j9ZCqcGFw9PxkOmCOx3jPKe+xkclE1rLIht/lNJd3GaNT8QuXTGcKz
FqRJ1Jd2a+Rt1/QXJhA/HjFGLTHrpAzFNfmzhCmoVtTJQ9fjw/JNJ7jzrX9p4V8i
guUBawWVCOOOED1ieg84qCZKIRzaIhgjvo8klELN1dvEKyjqzJUBI7qg1S6GePwy
rGMuWJHQcOnXvp9+PZ3V9Zs6hGB/NHzOuNJMZ+n8LEm13UGBEcoysRwdcfcZh+jE
D8NWxofsKeAveoNiKXIZxuZvYQN0RG7+BjBTBbTsr6z/Q/s4r4ll+baQ4lLReiPh
oC4VKwsTQ3hzpHPomY5r9ZEI3JQOuM8+I2ILLZ26xP+lWyTyrQ8CUEiOCVBPhx8A
TLRPydRp7V453E1/DjlB7L/oOC6ZBWZqg72kyBj3En8j8KVB1NRJcIuaBrMn+Fi4
0cgUCmOJQz1ep38j43vwGuRsCVWoZNZ18L2JhhViMFnPh6rw/SlcLSh00ei4cl7v
BEEJkeYNGyXxkozp7pj7I8CAm3gM3nyy6ULFd9X4vKVBnvnj7aTnQIH4hKd29z/u
UoNwHCHiSA==
=bA5c
-----END PGP SIGNATURE-----
Merge tag 'io_uring-6.10-20240614' of git://git.kernel.dk/linux
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
Three obvious driver 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).
Signed-off-by: James E.J. Bottomley <James.Bottomley@HansenParntership.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCZmw2AiYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishUaKAQCeqrej
+QoCHTaK7IJ8a5o8RmipBzU20GYG3+qew2Yu+QD+OvhSeGFLupgKuRYKemi+MI4r
/19hMZ0N774tCWr/BDw=
=0Al8
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of 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: 57e7c169cd ("bpf: Add __bpf_kfunc tag for marking kernel functions as kfuncs")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Yonghong Song <yonghong.song@linux.dev>
Closes: https://lore.kernel.org/r/202401211357.OCX9yllM-lkp@intel.com/
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 <tony.ambardar@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/bpf/ZlmGoT9KiYLZd91S@krava/T/
Link: https://lore.kernel.org/bpf/b31bca5a5e6765a0f32cc8c19b1d9cdbfaa822b5.1717477560.git.Tony.Ambardar@gmail.com
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).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmZsQmUSHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxyEwP/jBBYEeXi5vBq+UqEOtHVwgvN5hwXaTe
yrij1GhC25rea13itX2db3cffFXmrC+abixYa4tv1oXjtghKZtRofGJQe/URpLnG
mAIDChu4OPb1WQkMWz+ZeE0FAjCEPNPi/2d63mA65ZZVRAj7T/gw0wjUq/5Ib2ZH
Vcf3jUZ8sk92POb5EM1h1K5Nk57R8Ays3j5c8+D+w81Jzc2Cebm7K8kOEFoeWSVI
1MlDyekfUh/9u7ndGdMt29NdSwATxBUDuC6BsbfbrqbLEub6LDtFowBj64aJBnwC
HRsvIVvVbuMRhVPpodUmsBEPGCvwQCA/vBM8SuR0HDdvCBiRdxAm5kK3T0+I6TEU
fGciNt5VJBmzrhfEJ8tBoko85RJmuuwxX1CAdUbNiUBMMy4B6kdE8A/Hwd3oBFgp
fzMFxvk2e0YCgADdoCTI522M6IM9Mei7LfWa2E4jDC3E1Pjy78dpmL5fdiuQUlTD
zZLTcqoT+v6ztSyukR8szVbzqXOPKDqdlnuXMh6RGs5RloD4R1BZHD7r/TPqM9I6
I18BBKi63TexF0USYEwqia2kFDldW+u84XU0tgqIwBcOA0Y4u94RJXDkeymDLmhe
pbHnF7T16VpJ9OqqwoplhXu4p4xwkKNIFmBf7hTg7IKfHLOSJqyXUymwJOdq/tiH
OcXBuIkeTlRg
=LBok
-----END PGP SIGNATURE-----
Merge tag 'pm-6.10-rc4' of 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()
- 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).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmZsQe8SHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxJ4QQAJ6bD9c0gJ0EQD9B102Ree7corAsX7cl
5emlHGm7YfqMJSjczWfShbXZvQxrodTfPKBy0dfi+5pu52A609fp/iajarw62No8
1JeB87zI2SxuusqIExalvVu3Y4GPLH2f8S42buyzrituMlMIsB7YbpWBZawDDRab
b0qW2a7ZxHdjBnPy7+eyALmEaelzIQxJGttLbjKQYm8MbDA1vZpSv6/E+X2oYA4m
fCi8+hxiQrxsIIHsrhA9LzLuWBVStS/3iz/nyd5V0M96d/eJ+WB/3EXdfxBMhml4
m9pvHouQMzmwedb6m9IkdPJipN2wccy+RPmEd1hL9g3n+Nv7nGPBbA2yjH9Y/wjx
/Qkv0t/33q1h8bVxkT74NpQw7At8Hk89h9y/d2z9nx+YBJLql9dYYyBeIb7G94ML
Kbzcc6Cz6XHiGnGUjOOvP+b7dge5K1aL1dKNIr4842zYuIrd8p5s0D4zBuGKVCSH
L0Y7Uk1tEQfIIVGuUT5YGrlfHy/Czfv/k1D/rWqE9yRhqiOs02bcYxuVeCCFc9EP
ALkQ5/AA1K8M//PwZ8zHEWXRA5QvGW+5Q9kax8qJbRrMcwVH/k3N6pJ+0737x2XH
O+WBAgISpC1VUlp5fQVzPwxmzlzHSfjA67ERo3U4h/vIrG7fNp44g15+HZFC4dS0
P6iKtNIeA8OM
=eE4K
-----END PGP SIGNATURE-----
Merge tag 'acpi-6.10-rc4' of 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
- 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).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmZsQZASHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRx9OMP/1RX+WL0CIIaeuMFapZDmtNoflkl2HF/
Cx7S1ETc79dxgglZjlfNDi8Ebs9EHAgsqQlpbwNQA0959BideY5sFOgzbhdSYfs1
NhS+rDobXKNnmH7v3sABNNnRdQAsYC57WThNZVBBOmPyh3XCS2+JiRu2BZ3CpszO
pqotB+ayOEfbhswLWKfG5o36TbXiwpAsmfyl4bTJMxdAA+FwrcIlHYaDx0WaDGzN
NQhgz+PPg6Vu59eNu7N6/WInVL8k34/JMGhgseN1nHCZHhTUzl8TQfdBG761B4L4
+gLGaqFkIWm88EPlFYxyBSYqEISvi4Ap3vjBhbLMrGfQNJ//KjqEOdSz9C1fK2mF
BIZwpOq9W6ccL6IvznefkHRn7Qbjbk19etp4oG/CBvOW+n0bvRRv6atVckNZju4P
PMTzkLFTo6h6YN5PP6WCkbq3SsO7GacLWkpgiqedFdy5sophud7rcmuG9MR1XiFV
Ozvm7VV9ONJBtrv4Vx6uwmwerzl1qomCboOn1yCAq7WBvBaloKDRFWHlyqwrgzBP
FM0kByyEioF7aYdRB6kC7uZ11o3Fq9Z1TRlZZMsG1tmySdx2IL/AbmIyO4+KyQIV
jdM8xulNBT3DhcwoBgcK6LsyY7Q0iTTb5gR6t5ndjDUCljgCAMf0RXqewXoetg9/
mFkOuLLZKtYp
=bfRy
-----END PGP SIGNATURE-----
Merge tag 'thermal-6.10-rc4' of 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
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: 219eee9c0d ("net: skbuff: add overflow debug check to pull/push helpers")
Reported-by: syzbot+0c4150bff9fff3bf023c@syzkaller.appspotmail.com
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Closes: https://syzkaller.appspot.com/bug?extid=0c4150bff9fff3bf023c
Link: https://lore.kernel.org/netdev/9f254c96-54f2-4457-b7ab-1d9f6187939c@gmail.com/
Link: https://lore.kernel.org/bpf/20240614101801.9496-1-fw@strlen.de
The interface associated with the hda_component should be deactivated
before the driver is deconstructed during removal.
Fixes: 4e7914eb1d ("ALSA: hda/tas2781: remove sound controls in unbind")
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20240613133713.75550-4-simont@opensource.cirrus.com
The interface associated with the hda_component should be deactivated
before the driver is deconstructed during removal.
Fixes: 7b2f3eb492 ("ALSA: hda: cs35l41: Add support for CS35L41 in HDA systems")
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20240613133713.75550-3-simont@opensource.cirrus.com
The interface associated with the hda_component should be deactivated
before the driver is deconstructed during removal.
Fixes: 73cfbfa9ca ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier")
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20240613133713.75550-2-simont@opensource.cirrus.com
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 <jack@suse.cz>
Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240613163817.22640-1-chrubis@suse.cz
Signed-off-by: Jens Axboe <axboe@kernel.dk>
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 8a3e33cf92 ("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 dc8b4afc4a ("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
45b96d65ec ("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: 45b96d65ec ("ata: ahci: a hotplug capable port is an external port")
Cc: stable@vger.kernel.org
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Tested-by: Thomas Weißschuh <linux@weissschuh.net>
Reported-by: Thomas Weißschuh <linux@weissschuh.net>
Closes: https://lore.kernel.org/linux-ide/c0de8262-dc4b-4c22-9fac-33432e5bddd3@t-8ch.de/
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
[cassel: wrote commit message]
Signed-off-by: Niklas Cassel <cassel@kernel.org>
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: b5bfc8ab24 ("mfd: axp20x: Add support for AXP717 PMIC")
Reported-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: John Watts <contact@jookia.org>
Link: https://lore.kernel.org/r/20240613233104.17529-1-andre.przywara@arm.com
Signed-off-by: Lee Jones <lee@kernel.org>
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 <omosnace@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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: 014ab19a69 ("selinux: Set socket NetLabel based on connection endpoint")
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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 <keescook@chromium.org>
Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Kenton Groombridge <concord@gentoo.org>
Link: https://msgid.link/20240605152218.236061-1-concord@gentoo.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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 <kernel-bot@kylinos.cn>
Signed-off-by: pengfuyuan <pengfuyuan@kylinos.cn>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240606120842.1377267-1-pengfuyuan@kylinos.cn
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
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 <stern@rowland.harvard.edu>
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Reported-and-tested-by: syzbot+5f996b83575ef4058638@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/00000000000073d54b061a6a1c65@google.com/
Reported-and-tested-by: syzbot+1b2abad17596ad03dcff@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000f45085061aa9b37e@google.com/
Fixes: 9908a32e94 ("USB: remove err() macro from usb class drivers")
Link: https://lore.kernel.org/linux-usb/40dfa45b-5f21-4eef-a8c1-51a2f320e267@rowland.harvard.edu/
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/29855215-52f5-4385-b058-91f42c2bee18@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: 521223d7c2 ("io_uring/cancel: don't default to setting req->work.cancel_seq")
Cc: stable@vger.kernel.org
Reported-by: Li Shi <sl1589472800@gmail.com>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://lore.kernel.org/r/6827b129f8f0ad76fa9d1f0a773de938b240ffab.1718323430.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
- 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.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRskUM7w1oG5rx2IZO4FpNVCsYGvwUCZmrWQwAKCRC4FpNVCsYG
v5BIAP9gS5S9mRVp9h+vgo5U84h2VUDT3IoKBEFslkmhKuFATwEAsfbr2m3fD5RT
idAbg0enxy5V/etTB7oK/1TaSKFAqwo=
=ApmP
-----END PGP SIGNATURE-----
Merge tag 'drm-xe-fixes-2024-06-13' of 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 <airlied@redhat.com>
From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ZmrXV0FoBb8M0c6J@fedora
- Fix an regression issue by adding 640x480 fallback mode
for Exynos HDMI driver.
Bug fix
- Fix a memory leak by ensuring the duplicated EDID is properly freed in the get_modes function.
Code cleanup
- Remove redundant driver owner initialization since platform_driver_register() sets it automatically.
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEoxi+6c5pRPV/gdXcxWAb7Og/+bYFAmZmp5AACgkQxWAb7Og/
+baPmgv+NPpwekmg/MVid5E2UBPohPZ0qfB6AoDVUdN4vPYEzw5p9PRwcQ8vW/1u
K0rAGrmgGZZluYWz4OI0bQkA99Cxk6M9+knERxOtvODrf/G3oU2FVVq1s1u831Vo
wjjUMePrih2tpINrTu7EBTJSLVfOdsvkw3lOwfQlawrSm2YUZQKoWRpg4lL1bv9C
moXLnxDcz+DW3/Mv8GqfQwTxMwz5F1CSIqx/lJXzMo9FaR5B9mlgamCIRakEYkZo
CAqMASfDOyBWrbkSX3Yw7msmWWtZXEB5ICHsK4p8DGkaAEdzDGwDL1m8c0w/+0BU
sclpWXy01Y2fe22IJ/VwvAnFOGBY5+nNN47jkrDzgOwaPzC6Yaw9FUCPbnSIQBPs
eVfypoQxB5j9QsalxpTMmxzBZPGaa33mOuklsV2SGM7p4HJrf2NCDZCZiyp5Midp
bYpNEtZKjFzmb5+tov/sWegcZfo+qSBsN6JmHgFkt7ibJvaZGhj0/qnvMyyYEoTH
kArxG9kt
=ydsM
-----END PGP SIGNATURE-----
Merge tag 'exynos-drm-fixes-for-v6.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
Regression fix
- Fix an regression issue by adding 640x480 fallback mode
for Exynos HDMI driver.
Bug fix
- Fix a memory leak by ensuring the duplicated EDID is properly freed in the get_modes function.
Code cleanup
- Remove redundant driver owner initialization since platform_driver_register() sets it automatically.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240610073839.37430-1-inki.dae@samsung.com
This function wants to move a subset of a list from one element to the
tail into another list. It also needs to use the srcu synchronize
instead of the regular rcu version. Do this one element at a time
because that's the only to do it.
Fixes: be647e2c76 ("nvme: use srcu for iterating namespace list")
Reported-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
