In commit 9aeb68337a ("io_uring: get rid of remap_pfn_range() for
mapping rings/sqes") struct io_ring_ctx had some new fields added to fix
some security issues. This is an internal-to-the-io_uring-core
structure, but happens to have a pointer to this structure in other
structures that we track for ABI compliance. Because this is not an
"anonymous" pointer, it breaks the ABI checking. But as this is an
internal structure it is safe to change as no external module ever
accesses this structure at all.
The .stg update is:
type 'struct io_ring_ctx' changed
byte size changed from 1344 to 1408
member 'unsigned short n_ring_pages' was added
member 'unsigned short n_sqe_pages' was added
member 'struct page** ring_pages' was added
member 'struct page** sqe_pages' was added
Change-Id: I8029a8028271d85a19770702c024a4bac0746851
Fixes: 9aeb68337a ("io_uring: get rid of remap_pfn_range() for mapping rings/sqes")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
In commit 9aeb68337a ("io_uring: get rid of remap_pfn_range() for
mapping rings/sqes"), direct access to vm_flags was attempted, but
that's not allowed anymore in the Android 6.1 branch due to other
upstream changes merged into here. Fix this up by calling the proper
vm_flags_set() function instead.
Fixes: 9aeb68337a ("io_uring: get rid of remap_pfn_range() for mapping rings/sqes")
Change-Id: I05bdf96a2f6760e9388237d71d2471c373e29c0c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Steps on the way to 6.1.132
Resolves merge conflicts in:
kernel/sched/core.c
Change-Id: Idf7429c88e7e76a0fcb0479a6679b61ec35d7c82
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Changes in 6.1.131
ibmvnic: Perform tx CSO during send scrq direct
ibmvnic: Inspect header requirements before using scrq direct
drm/amdgpu: Check extended configuration space register when system uses large bar
drm/amdgpu: disable BAR resize on Dell G5 SE
cpuidle, intel_idle: Fix CPUIDLE_FLAG_IBRS
x86/speculation: Add __update_spec_ctrl() helper
x86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()
Revert "of: reserved-memory: Fix using wrong number of cells to get property 'alignment'"
LoongArch: Convert unreachable() to BUG()
HID: appleir: Fix potential NULL dereference at raw event handle
ksmbd: fix type confusion via race condition when using ipc_msg_send_request
ksmbd: fix use-after-free in smb2_lock
ksmbd: fix bug on trap in smb2_lock
gpio: rcar: Use raw_spinlock to protect register access
gpio: aggregator: protect driver attr handlers against module unload
ALSA: hda: intel: Add Dell ALC3271 to power_save denylist
ALSA: hda/realtek - add supported Mic Mute LED for Lenovo platform
ALSA: hda/realtek: update ALC222 depop optimize
drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_params
drm/radeon: Fix rs400_gpu_init for ATI mobility radeon Xpress 200M
platform/x86: thinkpad_acpi: Add battery quirk for ThinkPad X131e
x86/cacheinfo: Validate CPUID leaf 0x2 EDX output
x86/cpu: Validate CPUID leaf 0x2 EDX output
x86/cpu: Properly parse CPUID leaf 0x2 TLB descriptor 0x63
mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr
Bluetooth: Add check for mgmt_alloc_skb() in mgmt_remote_name()
Bluetooth: Add check for mgmt_alloc_skb() in mgmt_device_connected()
wifi: cfg80211: regulatory: improve invalid hints checking
wifi: nl80211: reject cooked mode if it is set along with other flags
rapidio: add check for rio_add_net() in rio_scan_alloc_net()
rapidio: fix an API misues when rio_add_net() fails
dma: kmsan: export kmsan_handle_dma() for modules
s390/traps: Fix test_monitor_call() inline assembly
block: fix conversion of GPT partition name to 7-bit
mm/page_alloc: fix uninitialized variable
mm: don't skip arch_sync_kernel_mappings() in error paths
wifi: iwlwifi: limit printed string from FW file
HID: google: fix unused variable warning under !CONFIG_ACPI
HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()
bluetooth: btusb: Initialize .owner field of force_poll_sync_fops
nvmet-tcp: Fix a possible sporadic response drops in weakly ordered arch
net: gso: fix ownership in __udp_gso_segment
caif_virtio: fix wrong pointer check in cfv_probe()
hwmon: (pmbus) Initialise page count in pmbus_identify()
hwmon: (ntc_thermistor) Fix the ncpXXxh103 sensor table
hwmon: (ad7314) Validate leading zero bits and return error
ALSA: usx2y: validate nrpacks module parameter on probe
llc: do not use skb_get() before dev_queue_xmit()
hwmon: fix a NULL vs IS_ERR_OR_NULL() check in xgene_hwmon_probe()
drm/sched: Fix preprocessor guard
be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink
net: hns3: make sure ptp clock is unregister and freed if hclge_ptp_get_cycle returns an error
ppp: Fix KMSAN uninit-value warning with bpf
vlan: enforce underlying device type
x86/sgx: Fix size overflows in sgx_encl_create()
exfat: fix soft lockup in exfat_clear_bitmap
net-timestamp: support TCP GSO case for a few missing flags
ublk: set_params: properly check if parameters can be applied
sched/fair: Fix potential memory corruption in child_cfs_rq_on_list
net: ipv6: fix dst ref loop in ila lwtunnel
net: ipv6: fix missing dst ref drop in ila lwtunnel
gpio: rcar: Fix missing of_node_put() call
Revert "drivers/card_reader/rtsx_usb: Restore interrupt based detection"
usb: renesas_usbhs: Call clk_put()
usb: renesas_usbhs: Use devm_usb_get_phy()
usb: hub: lack of clearing xHC resources
usb: quirks: Add DELAY_INIT and NO_LPM for Prolific Mass Storage Card Reader
usb: renesas_usbhs: Flush the notify_hotplug_work
usb: atm: cxacru: fix a flaw in existing endpoint checks
usb: dwc3: Set SUSPENDENABLE soon after phy init
usb: dwc3: gadget: Prevent irq storm when TH re-executes
usb: typec: ucsi: increase timeout for PPM reset operations
usb: typec: tcpci_rt1711h: Unmask alert interrupts to fix functionality
usb: gadget: Set self-powered based on MaxPower and bmAttributes
usb: gadget: Fix setting self-powered state on suspend
usb: gadget: Check bmAttributes only if configuration is valid
xhci: pci: Fix indentation in the PCI device ID definitions
usb: xhci: Enable the TRB overfetch quirk on VIA VL805
KVM: SVM: Drop DEBUGCTL[5:2] from guest's effective value
mei: me: add panther lake P DID
intel_th: pci: Add Arrow Lake support
intel_th: pci: Add Panther Lake-H support
intel_th: pci: Add Panther Lake-P/U support
drivers: core: fix device leak in __fw_devlink_relax_cycles()
slimbus: messaging: Free transaction ID in delayed interrupt scenario
bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock
eeprom: digsy_mtc: Make GPIO lookup table match the device
drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctl
iio: filter: admv8818: Force initialization of SDO
iio: dac: ad3552r: clear reset status flag
iio: adc: at91-sama5d2_adc: fix sama7g5 realbits value
ALSA: hda: realtek: fix incorrect IS_REACHABLE() usage
Revert "KVM: e500: always restore irqs"
Revert "KVM: PPC: e500: Use __kvm_faultin_pfn() to handle page faults"
Revert "KVM: PPC: e500: Mark "struct page" pfn accessed before dropping mmu_lock"
Revert "KVM: PPC: e500: Mark "struct page" dirty in kvmppc_e500_shadow_map()"
uprobes: Fix race in uprobe_free_utask
x86/mm: Don't disable PCID when INVLPG has been fixed by microcode
spi-mxs: Fix chipselect glitch
nilfs2: move page release outside of nilfs_delete_entry and nilfs_set_link
nilfs2: eliminate staggered calls to kunmap in nilfs_rename
nilfs2: handle errors that nilfs_prepare_chunk() may return
scsi: lpfc: Fix a possible data race in lpfc_unregister_fcf_rescan()
media: mediatek: vcodec: Handle invalid decoder vsi
fs/ntfs3: Add rough attr alloc_size check
bpf, vsock: Invoke proto::close on close()
vsock: Keep the binding until socket destruction
vsock: Orphan socket after transport release
kbuild: userprogs: use correct lld when linking through clang
Linux 6.1.131
Change-Id: I846b7da7fcd491297aaa93f644bbd9deb3ec14e8
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
In the android14-6.1-lts branch, a few new include files were added to
net/ipv4/icmp.c, which ended up changing the CRC generation for
__icmp_send. This did not show up in the -lts branch as that symbol was
not being tracked there, BUT it was added to the non-LTS branch, which
caused the mis-match to show up when merging them together.
Fix this up by providing the proper __GENKSYMS__ hack to enable the CRC
to remain stable.
Fixes: eaba5f6743 ("ipv4: icmp: Unmask upper DSCP bits in icmp_route_lookup()")
Fixes: 524c341cb1 ("net/ipv4: add tracepoint for icmp_send")
Change-Id: If28644b3fa4c474de4d2b08eef50e84b19685d74
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Catch the -lts branch up with what is in the normal branch. Changes in
here are:
* 1c9aeb1ce3 Merge tag 'android14-6.1.129_r00' into android14-6.1
* b18db21117 ANDROID: GKI: Update rockchip symbols for drm driver.
* f628136006 ANDROID: ABI: Update pixel symbol list
* 2fb96ec85c ANDROID: vendor_hook: add vendor hook on calculate_totalreserve_pages
* 5145d15773 ANDROID: GKI: update symbol list file for xiaomi
* 2f4537ba6c ANDROID: vendor_hooks: Skip pages with high memory pressure in shrink_active_list
* da6a42c111 FROMGIT: mm/page_alloc: add trace event for totalreserve_pages calculation
* 95baed1663 BACKPORT: FROMGIT: mm/page_alloc: add trace event for per-zone lowmem reserve setup
* 9d6305174c BACKPORT: FROMGIT: mm/page_alloc: add trace event for per-zone watermark setup
* 7da329f7cf ANDROID: Update the ABI symbol list
* d3b0aaa092 ANDROID: Add EXPORT_SYMBOL_GPL for folio_mapcount
* 6bd3e435f2 UPSTREAM: f2fs: fix inconsistent dirty state of atomic file
* 2afd0800a7 UPSTREAM: net: avoid race between device unregistration and ethnl ops
* 92ada4b4c2 UPSTREAM: pfifo_tail_enqueue: Drop new packet when sch->limit == 0
* cd0ebcd175 UPSTREAM: vsock: Orphan socket after transport release
* 7f11cc02d9 UPSTREAM: vsock: Keep the binding until socket destruction
* e2647b0fb4 UPSTREAM: bpf, vsock: Invoke proto::close on close()
* cfa792a776 FROMGIT: f2fs: fix to avoid atomicity corruption of atomic file
* f3c4686f77 ANDROID: abi_gki_aarch64_qcom: Add xas_load
* 33c9d4844a ANDROID: Update the ABI symbol list
* 0ad7fae66c ANDROID: printk: add vendor hook to logging during hibernation
* 4da91a8e56 BACKPORT: FROMGIT: f2fs: fix to avoid running out of free segments
* 64560e780e BACKPORT: FROMGIT: f2fs: fix to avoid panic once fallocation fails for pinfile
* 27895588a2 BACKPORT: f2fs: compress: fix inconsistent update of i_blocks in release_compress_blocks and reserve_compress_blocks
* 70d032fba5 ANDROID: GKI: Add KMI symbol list for zebra
* efd0bedd2c ANDROID: GKI: Update rockchip symbols for drm driver.
* 69a6dfc9c3 ANDROID: GKI: Update symbol list for mtk
* 9bcabbda67 ANDROID: userfaultfd: add MOVE ioctl mode to confirm bug-fixes
* 8d8d44ff91 FROMGIT: userfaultfd: fix PTE unmapping stack-allocated PTE copies
* af439accc7 FROMGIT: userfaultfd: do not block on locking a large folio with raised refcount
* 7d6124b604 FROMGIT: BACKPORT: mm: fix kernel BUG when userfaultfd_move encounters swapcache
* 44db4837f7 ANDROID: Update the ABI symbol list
* 50eddb3fc9 FROMGIT: f2fs: set highest IO priority for checkpoint thread
* 471a10d3af ANDROID: mm/memfd-ashmem-shim: Fix variable length array usage
* 6b227a1f74 ANDROID: GKI: Update symbol list for xiaomi
* eaffa3e341 ANDROID: mm: add a new vendor hook in filemap_map_pages
* fa3cc11118 ANDROID: GKI: Enable CONFIG_MEMFD_ASHMEM_SHIM
* 6355ece3ca ANDROID: mm: shmem: Use memfd-ashmem-shim ioctl handler
* 004c31328a ANDROID: mm/memfd-ashmem-shim: Introduce shim layer
* b4fef39187 ANDROID: ashmem: Add toggle to ignore requests to deny PROT_EXEC mappings
* ef10c0ef7d ANDROID: ashmem: Add toggle to ignore requests to deny PROT_READ mappings
* 9f6b96dfca ANDROID: ashmem: Add support for disabling unpinning feature
* 4deb2cd703 ANDROID: Update the ABI symbol list
* 75c1d11b88 ANDROID: swapfile: Add EXPORT_SYMBOL_GPL for page_swap_info
* f27efe75fc UPSTREAM: io_uring: fix io_req_prep_async with provided buffers
* 719cffaab0 ANDROID: GKI: Update symbol list for BCMSTB
* 6ad8aa12e1 ANDROID: abi_gki_aarch64_qcom: Update symbol list
* 45755ee7b6 ANDROID: of: add export symbol for of_update_property
* cf7683f719 ANDROID: GKI: Update oplus symbol list
Change-Id: I8da40828d5179139546e9bc8b15efdbae9bc57de
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Commit 3ab1db3c6039e02a9deb9d5091d28d559917a645 upstream.
Rather than use remap_pfn_range() for this and manually free later,
switch to using vm_insert_pages() and have it Just Work.
If possible, allocate a single compound page that covers the range that
is needed. If that works, then we can just use page_address() on that
page. If we fail to get a compound page, allocate single pages and use
vmap() to map them into the kernel virtual address space.
This just covers the rings/sqes, the other remaining user of the mmap
remap_pfn_range() user will be converted separately. Once that is done,
we can kill the old alloc/free code.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 62346c6cb28b043f2a6e95337d9081ec0b37b5f5 upstream.
An identical one exists for vm_insert_page(), add one for
vm_insert_pages() to avoid needing to check for CONFIG_MMU in code using
it.
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 9c189eee73 upstream.
We do rings and sqes separately, move them into a helper that does both
the freeing and clearing of the memory.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit e27cef86a0 upstream.
In preparation for having more than one time of ring allocator, make the
existing one return valid/error-pointer rather than just NULL.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit b654f7a51ffb386131de42aa98ed831f8c126546 ]
Device mapper bioset often has big bio_slab size, which can be more than
1000, then 8byte can't hold the slab name any more, cause the kmem_cache
allocation warning of 'kmem_cache of name 'bio-108' already exists'.
Fix the warning by extending bio_slab->name to 12 bytes, but fix output
of /proc/slabinfo
Reported-by: Guangwu Zhang <guazhang@redhat.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20250228132656.2838008-1-ming.lei@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9de7695925d5d2d2085681ba935857246eb2817d ]
When both of X86_LOCAL_APIC and X86_THERMAL_VECTOR are disabled,
the irq tracing produces a W=1 build warning for the tracing
definitions:
In file included from include/trace/trace_events.h:27,
from include/trace/define_trace.h:113,
from arch/x86/include/asm/trace/irq_vectors.h:383,
from arch/x86/kernel/irq.c:29:
include/trace/stages/init.h:2:23: error: 'str__irq_vectors__trace_system_name' defined but not used [-Werror=unused-const-variable=]
Make the tracepoints conditional on the same symbosl that guard
their usage.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20250225213236.3141752-1-arnd@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a26b24b2e21f6222635a95426b9ef9eec63d69b1 ]
Freqency mode is the current default mode of Linux perf. A period of 1 is
used as a starting period. The period is auto-adjusted on each tick or an
overflow, to meet the frequency target.
The start period of 1 is too low and may trigger some issues:
- Many HWs do not support period 1 well.
https://lore.kernel.org/lkml/875xs2oh69.ffs@tglx/
- For an event that occurs frequently, period 1 is too far away from the
real period. Lots of samples are generated at the beginning.
The distribution of samples may not be even.
- A low starting period for frequently occurring events also challenges
virtualization, which has a longer path to handle a PMI.
The limit_period value only checks the minimum acceptable value for HW.
It cannot be used to set the start period, because some events may
need a very low period. The limit_period cannot be set too high. It
doesn't help with the events that occur frequently.
It's hard to find a universal starting period for all events. The idea
implemented by this patch is to only give an estimate for the popular
HW and HW cache events. For the rest of the events, start from the lowest
possible recommended value.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250117151913.3043942-3-kan.liang@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b4c173dfbb6c78568578ff18f9e8822d7bd0e31b ]
Fuse allows the value of a symlink to change and this property is exploited
by some filesystems (e.g. CVMFS).
It has been observed, that sometimes after changing the symlink contents,
the value is truncated to the old size.
This is caused by fuse_getattr() racing with fuse_reverse_inval_inode().
fuse_reverse_inval_inode() updates the fuse_inode's attr_version, which
results in fuse_change_attributes() exiting before updating the cached
attributes
This is okay, as the cached attributes remain invalid and the next call to
fuse_change_attributes() will likely update the inode with the correct
values.
The reason this causes problems is that cached symlinks will be
returned through page_get_link(), which truncates the symlink to
inode->i_size. This is correct for filesystems that don't mutate
symlinks, but in this case it causes bad behavior.
The solution is to just remove this truncation. This can cause a
regression in a filesystem that relies on supplying a symlink larger than
the file size, but this is unlikely. If that happens we'd need to make
this behavior conditional.
Reported-by: Laura Promberger <laura.promberger@cern.ch>
Tested-by: Sam Lewis <samclewis@google.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Link: https://lore.kernel.org/r/20250220100258.793363-1-mszeredi@redhat.com
Reviewed-by: Bernd Schubert <bschubert@ddn.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d2fe192348f93fe3a0cb1e33e4aba58e646397f4 ]
The fabric transports and also the PCI transport are not entering the
LIVE state from NEW or RESETTING. This makes the state machine more
restrictive and allows to catch not supported state transitions, e.g.
directly switching from RESETTING to LIVE.
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Daniel Wagner <wagi@kernel.org>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 606572eb22c1786a3957d24307f5760bb058ca19 ]
According to the C11 standard (ISO/IEC 9899:2011, 6.5.7):
"If E1 has a signed type and E1 x 2^E2 is not representable in the result
type, the behavior is undefined."
Shifting 1 << 31 causes signed integer overflow, which leads to undefined
behavior.
Fix this by explicitly using '1U << 31' to ensure the shift operates on
an unsigned type, avoiding undefined behavior.
Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com>
Link: https://patch.msgid.link/20250218081217.3468369-1-eleanor15x@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3988ac1c67e6e84d2feb987d7b36d5791174b3da ]
The queue state checking in nvmet_rdma_recv_done is not in queue state
lock.Queue state can transfer to LIVE in cm establish handler between
state checking and state lock here, cause a silent drop of nvme connect
cmd.
Recheck queue state whether in LIVE state in state lock to prevent this
issue.
Signed-off-by: Ruozhu Li <david.li@jaguarmicro.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 84e009042d0f3dfe91bec60bcd208ee3f866cbcd ]
Previously, the NVMe/TCP host driver did not handle the C2HTermReq PDU,
instead printing "unsupported pdu type (3)" when received. This patch adds
support for processing the C2HTermReq PDU, allowing the driver
to print the Fatal Error Status field.
Example of output:
nvme nvme4: Received C2HTermReq (FES = Invalid PDU Header Field)
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit fcd875445866a5219cf2be3101e276b21fc843f3 ]
In order for two Acer FA100 SSDs to work in one PC (in the case of
myself, a Lenovo Legion T5 28IMB05), and not show one drive and not
the other, and sometimes mix up what drive shows up (randomly), these
two lines of code need to be added, and then both of the SSDs will
show up and not conflict when booting off of one of them. If you boot
up your computer with both SSDs installed without this patch, you may
also randomly get into a kernel panic (if the initrd is not set up) or
stuck in the initrd "/init" process, it is set up, however, if you do
apply this patch, there should not be problems with booting or seeing
both contents of the drive. Tested with the btrfs filesystem with a
RAID configuration of having the root drive '/' combined to make two
256GB Acer FA100 SSDs become 512GB in total storage.
Kernel Logs with patch applied (`dmesg -t | grep -i nvm`):
```
...
nvme 0000:04:00.0: platform quirk: setting simple suspend
nvme nvme0: pci function 0000:04:00.0
nvme 0000:05:00.0: platform quirk: setting simple suspend
nvme nvme1: pci function 0000:05:00.0
nvme nvme1: missing or invalid SUBNQN field.
nvme nvme1: allocated 64 MiB host memory buffer.
nvme nvme0: missing or invalid SUBNQN field.
nvme nvme0: allocated 64 MiB host memory buffer.
nvme nvme1: 8/0/0 default/read/poll queues
nvme nvme1: Ignoring bogus Namespace Identifiers
nvme nvme0: 8/0/0 default/read/poll queues
nvme nvme0: Ignoring bogus Namespace Identifiers
nvme0n1: p1 p2
...
```
Kernel Logs with patch not applied (`dmesg -t | grep -i nvm`):
```
...
nvme 0000:04:00.0: platform quirk: setting simple suspend
nvme nvme0: pci function 0000:04:00.0
nvme 0000:05:00.0: platform quirk: setting simple suspend
nvme nvme1: pci function 0000:05:00.0
nvme nvme0: missing or invalid SUBNQN field.
nvme nvme1: missing or invalid SUBNQN field.
nvme nvme0: allocated 64 MiB host memory buffer.
nvme nvme1: allocated 64 MiB host memory buffer.
nvme nvme0: 8/0/0 default/read/poll queues
nvme nvme1: 8/0/0 default/read/poll queues
nvme nvme1: globally duplicate IDs for nsid 1
nvme nvme1: VID:DID 1dbe:5216 model:Acer SSD FA100 256GB firmware:1.Z.J.2X
nvme0n1: p1 p2
...
```
Signed-off-by: Christopher Lentocha <christopherericlentocha@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0d1fac6d26aff5df21bb4ec980d9b7a11c410b96 ]
When using the Qualcomm X55 modem on the ThinkPad X13s, the kernel log is
constantly being filled with errors related to a "sequence number glitch",
e.g.:
[ 1903.284538] sequence number glitch prev=16 curr=0
[ 1913.812205] sequence number glitch prev=50 curr=0
[ 1923.698219] sequence number glitch prev=142 curr=0
[ 2029.248276] sequence number glitch prev=1555 curr=0
[ 2046.333059] sequence number glitch prev=70 curr=0
[ 2076.520067] sequence number glitch prev=272 curr=0
[ 2158.704202] sequence number glitch prev=2655 curr=0
[ 2218.530776] sequence number glitch prev=2349 curr=0
[ 2225.579092] sequence number glitch prev=6 curr=0
Internet connectivity is working fine, so this error seems harmless. It
looks like modem does not preserve the sequence number when entering low
power state; the amount of errors depends on how actively the modem is
being used.
A similar issue has also been seen on USB-based MBIM modems [1]. However,
in cdc_ncm.c the "sequence number glitch" message is a debug message
instead of an error. Apply the same to the mhi_wwan_mbim.c driver to
silence these errors when using the modem.
[1]: https://lists.freedesktop.org/archives/libmbim-devel/2016-November/000781.html
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://patch.msgid.link/20250212-mhi-wwan-mbim-sequence-glitch-v1-1-503735977cbd@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c3fc002b206c6c83d1e3702b979733002ba6fb2c ]
rsnd_kctrl_accept_runtime() (1) is used for runtime convert rate
(= Synchronous SRC Mode). Now, rsnd driver has 2 kctrls for it
(A): "SRC Out Rate Switch"
(B): "SRC Out Rate" // it calls (1)
(A): can be called anytime
(B): can be called only runtime, and will indicate warning if it was used
at non-runtime.
To use runtime convert rate (= Synchronous SRC Mode), user might uses
command in below order.
(X): > amixer set "SRC Out Rate" on
> aplay xxx.wav &
(Y): > amixer set "SRC Out Rate" 48010 // convert rate to 48010Hz
(Y): calls B
(X): calls both A and B.
In this case, when user calls (X), it calls both (A) and (B), but it is not
yet start running. So, (B) will indicate warning.
This warning was added by commit b5c0886898 ("ASoC: rsnd: add warning
message to rsnd_kctrl_accept_runtime()"), but the message sounds like the
operation was not correct. Let's update warning message.
The message is very SRC specific, implement it in src.c
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://patch.msgid.link/8734gt2qed.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 32ae4a2992529e2c7934e422035fad1d9b0f1fb5 ]
In some environments, the SCLP firmware interface used to query a
CHPID's configured state is not supported. On these environments,
rapidly reading the corresponding sysfs attribute produces inconsistent
results:
$ cat /sys/devices/css0/chp0.00/configure
cat: /sys/devices/css0/chp0.00/configure: Operation not supported
$ cat /sys/devices/css0/chp0.00/configure
3
This occurs for example when Linux is run as a KVM guest. The
inconsistency is a result of CIO using cached results for generating
the value of the "configure" attribute while failing to handle the
situation where no data was returned by SCLP.
Fix this by not updating the cache-expiration timestamp when SCLP
returns no data. With the fix applied, the system response is
consistent:
$ cat /sys/devices/css0/chp0.00/configure
cat: /sys/devices/css0/chp0.00/configure: Operation not supported
$ cat /sys/devices/css0/chp0.00/configure
cat: /sys/devices/css0/chp0.00/configure: Operation not supported
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Tested-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 819083cb6eedcc8495cbf84845877bcc741b93b3 ]
The Omoton KB066 is an Apple A1255 keyboard clone (HID product code
05ac:022c). On both keyboards, the F6 key becomes Num Lock when the Fn
key is held. But unlike its Apple exemplar, when the Omoton's F6 key is
pressed without Fn, it sends the usage code 0xC0301 from the reserved
section of the consumer page instead of the standard F6 usage code
0x7003F from the keyboard page. The nonstandard code is translated to
KEY_UNKNOWN and becomes useless on Linux. The Omoton KB066 is a pretty
popular keyboard, judging from its 29,058 reviews on Amazon at time of
writing, so let's account for its quirk to make it more usable.
By the way, it would be nice if we could automatically set fnmode to 0
for Omoton keyboards because they handle the Fn key internally and the
kernel's Fn key handling creates undesirable side effects such as making
F1 and F2 always Brightness Up and Brightness Down in fnmode=1 (the
default) or always F1 and F2 in fnmode=2. Unfortunately I don't think
there's a way to identify Bluetooth keyboards more specifically than the
HID product code which is obviously inaccurate. Users of Omoton
keyboards will just have to set fnmode to 0 manually to get full Fn key
functionality.
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2813e00dcd748cef47d2bffaa04071de93fddf00 ]
Add Apple Magic Keyboard 2024 model (with USB-C port) device ID (0320)
to those recognized by the hid-apple driver. Keyboard is otherwise
compatible with the existing implementation for its earlier 2021 model.
Signed-off-by: Ievgen Vovk <YevgenVovk@ukr.net>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 363236d709e75610b628c2a4337ccbe42e454b6d ]
The HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface that
is not actually implemented. Attempting to access this non-functional
sensor via iio_info causes system hangs as runtime PM tries to wake up
an unresponsive sensor.
[453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff
[453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffff
Add this device to the HID ignore list since the sensor interface is
non-functional by design and should not be exposed to userspace.
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7e0d1cff12b895f44f4ddc8cf50311bc1f775201 ]
The ISH driver performs a clock sync with the firmware once at system
startup and then every 20 seconds. If a firmware reset occurs right
after a clock sync, the driver would wait 20 seconds before performing
another clock sync with the firmware. This is particularly problematic
with the introduction of the "load firmware from host" feature, where
the driver performs a clock sync with the bootloader and then has to
wait 20 seconds before syncing with the main firmware.
This patch clears prev_sync immediately upon receiving an IPC reset,
so that the main firmware and driver will perform a clock sync
immediately after completing the IPC handshake.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4b54ae69197b9f416baa0fceadff7e89075f8454 ]
The timestamps in the Firmware log and HID sensor samples are incorrect.
They show 1970-01-01 because the current IPC driver only uses the first
8 bytes of bootup time when synchronizing time with the firmware. The
firmware converts the bootup time to UTC time, which results in the
display of 1970-01-01.
In write_ipc_from_queue(), when sending the MNG_SYNC_FW_CLOCK message,
the clock is updated according to the definition of ipc_time_update_msg.
However, in _ish_sync_fw_clock(), the message length is specified as the
size of uint64_t when building the doorbell. As a result, the firmware
only receives the first 8 bytes of struct ipc_time_update_msg.
This patch corrects the length in the doorbell to ensure the entire
ipc_time_update_msg is sent, fixing the timestamp issue.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b029628be267cba3c7684ec684749fe3e4372398 ]
Richard Henderson <richard.henderson@linaro.org> writes[1]:
> There was a Spec benchmark (I forget which) which was memory bound and ran
> twice as fast with 32-bit pointers.
>
> I copied the idea from DEC to the ELF abi, but never did all the other work
> to allow the toolchain to take advantage.
>
> Amusingly, a later Spec changed the benchmark data sets to not fit into a
> 32-bit address space, specifically because of this.
>
> I expect one could delete the ELF bit and personality and no one would
> notice. Not even the 10 remaining Alpha users.
In [2] it was pointed out that parts of setarch weren't working
properly on alpha because it has it's own SET_PERSONALITY
implementation. In the discussion that followed Richard Henderson
pointed out that the 32bit pointer support for alpha was never
completed.
Fix this by removing alpha's 32bit pointer support.
As a bit of paranoia refuse to execute any alpha binaries that have
the EF_ALPHA_32BIT flag set. Just in case someone somewhere has
binaries that try to use alpha's 32bit pointer support.
Link: https://lkml.kernel.org/r/CAFXwXrkgu=4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq4ttm52pJOQ@mail.gmail.com [1]
Link: https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-berlin.de [2]
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://lore.kernel.org/r/87y0zfs26i.fsf_-_@email.froward.int.ebiederm.org
Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 773dc23ff81838b6f74d7fabba5a441cc6a93982 ]
When the client attempts to tree connect to a domain-based DFS
namespace from a DFS interlink target, the server will return
STATUS_BAD_NETWORK_NAME and the following will appear on dmesg:
CIFS: VFS: BAD_NETWORK_NAME: \\dom\dfs
Since a DFS share might contain several DFS interlinks and they expire
after 10 minutes, the above message might end up being flooded on
dmesg when mounting or accessing them.
Print this only once per share.
Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5233e3235dec3065ccc632729675575dbe3c6b8a ]
A null dereference or oops exception will eventually occur when qla1280.c
driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. I
think its clear from the code that the intention here is sg_dma_len(s) not
length of sg_next(s) when printing the debug info.
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
Link: https://lore.kernel.org/r/20250125095033.26188-1-linmag7@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
