Jakub Kicinski [Thu, 25 Nov 2021 01:02:43 +0000 (17:02 -0800)]
Merge tag 'ieee802154-for-net-2021-11-24' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan
Stefan Schmidt says:
====================
pull-request: ieee802154 for net 2021-11-24
A fix from Alexander which has been brought up various times found by
automated checkers. Make sure values are in u32 range.
* tag 'ieee802154-for-net-2021-11-24' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan:
net: ieee802154: handle iftypes as u32
====================
Longpeng [Wed, 24 Nov 2021 01:52:15 +0000 (09:52 +0800)]
vdpa_sim: avoid putting an uninitialized iova_domain
The system will crash if we put an uninitialized iova_domain, this
could happen when an error occurs before initializing the iova_domain
in vdpasim_create().
vhost/vsock: fix incorrect used length reported to the guest
The "used length" reported by calling vhost_add_used() must be the
number of bytes written by the device (using "in" buffers).
In vhost_vsock_handle_tx_kick() the device only reads the guest
buffers (they are all "out" buffers), without writing anything,
so we must pass 0 as "used length" to comply virtio spec.
Attempts to validate length in the core did not work out: there turn out
to exist multiple broken devices, and in particular legacy devices are
known to be broken in this respect.
We have ideas for handling this better in the next version but for now
let's revert to a known good state to make sure drivers work for people.
Alex Deucher [Tue, 23 Nov 2021 15:44:48 +0000 (10:44 -0500)]
drm/amd/display: update bios scratch when setting backlight
Update the bios scratch register when updating the backlight
level. Some platforms apparently read this scratch register
and do additional operations in their hotkey handlers.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1518 Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Philip Yang [Tue, 23 Nov 2021 15:20:17 +0000 (10:20 -0500)]
drm/amdgpu: enable Navi retry fault wptr overflow
If xnack is on, VM retry fault interrupt send to IH ring1, and ring1
will be full quickly. IH cannot receive other interrupts, this causes
deadlock if migrating buffer using sdma and waiting for sdma done
while handling retry fault.
Remove VMC from IH storm client, enable ring1 write pointer
overflow, then IH will drop retry fault interrupts and be able to receive
other interrupts while driver is handling retry fault.
IH ring1 write pointer doesn't writeback to memory by IH, and ring1
write pointer recorded by self-irq is not updated, so always read
the latest ring1 write pointer from register.
Philip Yang [Fri, 19 Nov 2021 22:02:50 +0000 (17:02 -0500)]
drm/amdkfd: simplify drain retry fault
unmap range always increase atomic svms->drain_pagefaults to simplify
both parent range and child range unmap, page fault handle ignores the
retry fault if svms->drain_pagefaults is set to speed up interrupt
handling. svm_range_drain_retry_fault restart draining if another
range unmap from cpu.
Philip Yang [Fri, 19 Nov 2021 21:16:39 +0000 (16:16 -0500)]
drm/amdkfd: handle VMA remove race
VMA may be removed before unmap notifier callback, and deferred list
work remove range, return success for this special case as we are
handling stale retry fault.
Philip Yang [Tue, 16 Nov 2021 16:45:32 +0000 (11:45 -0500)]
drm/amdkfd: process exit and retry fault race
kfd_process_wq_release drain retry fault to ensure no retry fault comes
after removing kfd process from the hash table, otherwise svm page fault
handler will fail to recover the fault and dump GPU vm fault log.
Refactor deferred list work to get_task_mm and take mmap write lock
to handle all ranges, and avoid mm is gone while inserting mmu notifier.
shaoyunl [Thu, 18 Nov 2021 16:43:16 +0000 (11:43 -0500)]
drm/amdgpu: move kfd post_reset out of reset_sriov function
Fixes: 9f4f2c1a3524 ("drm/amd/amdgpu: fix the kfd pre_reset sequence in sriov")
For sriov XGMI configuration, the host driver will handle the hive reset,
so in guest side, the reset_sriov only be called once on one device. This will
make kfd post_reset unblanced with kfd pre_reset since kfd pre_reset already
been moved out of reset_sriov function. Move kfd post_reset out of reset_sriov
function to make them balance .
This is not expected behavior and may result in link encoders being
incorrectly assigned.
[How]
The dc->current_state is backed up into dm->cached_dc_state before
we commit 0 streams.
DC will clear link encoder assignments on the real state but the
changes won't propagate over to the copy we made before the
0 streams commit.
DC expects that link encoder assignments are *not* valid
when committing a state, so as a workaround it needs to be cleared
before passing it back into DC.
drm/amd/display: Fix DPIA outbox timeout after GPU reset
[Why]
The HW interrupt gets disabled after GPU reset so we don't receive
notifications for HPD or AUX from DMUB - leading to timeout and
black screen with (or without) DPIA links connected.
[How]
Re-enable the interrupt after GPU reset like we do for the other
DC interrupts.
xinhui pan [Fri, 19 Nov 2021 10:08:31 +0000 (18:08 +0800)]
drm/amdgpu: Fix double free of dmabuf
amdgpu_amdkfd_gpuvm_free_memory_of_gpu drop dmabuf reference increased in
amdgpu_gem_prime_export.
amdgpu_bo_destroy drop dmabuf reference increased in
amdgpu_gem_prime_import.
So remove this extra dma_buf_put to avoid double free.
Change iomap_read_inline_data to return 0 or an error code; this
simplifies the callers. Add a description.
Signed-off-by: Andreas Gruenbacher <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
[djwong: document the return value of iomap_read_inline_data explicitly] Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
Yang Xu [Wed, 24 Nov 2021 18:06:02 +0000 (10:06 -0800)]
xfs: Fix the free logic of state in xfs_attr_node_hasname
When testing xfstests xfs/126 on lastest upstream kernel, it will hang on some machine.
Adding a getxattr operation after xattr corrupted, I can reproduce it 100%.
When getxattr calls xfs_attr_node_get function, xfs_da3_node_lookup_int fails with EFSCORRUPTED in
xfs_attr_node_hasname because we have use blocktrash to random it in xfs/126. So it
free state in internal and xfs_attr_node_get doesn't do xfs_buf_trans release job.
Then subsequent removexattr will hang because of it.
This bug was introduced by kernel commit 07120f1abdff ("xfs: Add xfs_has_attr and subroutines").
It adds xfs_attr_node_hasname helper and said caller will be responsible for freeing the state
in this case. But xfs_attr_node_hasname will free state itself instead of caller if
xfs_da3_node_lookup_int fails.
Fix this bug by moving the step of free state into caller.
Also, use "goto error/out" instead of returning error directly in xfs_attr_node_addname_find_attr and
xfs_attr_node_removename_setup function because we should free state ourselves.
Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") Signed-off-by: Yang Xu <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
Update the USB serial option driver support for the Fibocom
FM101-GL Cat.6
LTE modules as there are actually several different variants.
- VID:PID 2cb7:01a2, FM101-GL are laptop M.2 cards (with
MBIM interfaces for /Linux/Chrome OS)
- VID:PID 2cb7:01a4, FM101-GL for laptop debug M.2 cards(with adb
interface for /Linux/Chrome OS)
Linus Torvalds [Wed, 24 Nov 2021 17:55:24 +0000 (09:55 -0800)]
Merge tag 'for-5.16/parisc-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc fixes from Helge Deller:
"Increase the FRAME_WARN value to avoid some new warnings which showed
up in the Linux kernel test project, revert a patch which moved the
_stext symbol and thus tiggered errors in the hardened usercopy
checks, and introduce an extru_safe() assembler macro to overcome
possible unsafe usage of the extru asm statement on 64-bit PA2.0
machines"
* tag 'for-5.16/parisc-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
Revert "parisc: Fix backtrace to always include init funtion names"
parisc: Convert PTE lookup to use extru_safe() macro
parisc: Fix extraction of hash lock bits in syscall.S
parisc: Provide an extru_safe() macro to extract unsigned bits
parisc: Increase FRAME_WARN to 2048 bytes on parisc
Linus Torvalds [Wed, 24 Nov 2021 17:51:22 +0000 (09:51 -0800)]
Merge tag 'trace-v5.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fix from Steven Rostedt:
"Fix wrong uprobe variable in iterator
uprobe_perf_open() processes a list of probes, but due to a missing
setting of the uprobe to be processed, the loop processes the head
probe instead of the added probes"
* tag 'trace-v5.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing/uprobe: Fix uprobe_perf_open probes iteration
Linus Torvalds [Wed, 24 Nov 2021 17:44:13 +0000 (09:44 -0800)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID fixes from Jiri Kosina:
- fix for Intel-ISH driver to make sure it gets aoutoloaded only on
matching devices and not universally (Thomas Weißschuh)
- fix for Wacom driver reporting invalid contact under certain
circumstances (Jason Gerecke)
- probing fix for ft260 dirver (Michael Zaidman)
- fix for generic keycode remapping (Thomas Weißschuh)
- fix for division by zero in hid-magicmouse (Claudia Pellegrino)
- other tiny assorted fixes and new device IDs
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
HID: multitouch: Fix Iiyama ProLite T1931SAW (0eef:0001 again!)
HID: nintendo: eliminate dead datastructures in !CONFIG_NINTENDO_FF case
HID: magicmouse: prevent division by 0 on scroll
HID: thrustmaster: fix sparse warnings
HID: Ignore battery for Elan touchscreen on HP Envy X360 15-eu0xxx
HID: input: set usage type to key on keycode remap
HID: input: Fix parsing of HID_CP_CONSUMER_CONTROL fields
HID: ft260: fix i2c probing for hwmon devices
Revert "HID: hid-asus.c: Maps key 0x35 (display off) to KEY_SCREENLOCK"
HID: intel-ish-hid: fix module device-id handling
mod_devicetable: fix kdocs for ishtp_device_id
HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts
HID: nintendo: unlock on error in joycon_leds_create()
platform/x86: isthp_eclite: only load for matching devices
platform/chrome: chros_ec_ishtp: only load for matching devices
HID: intel-ish-hid: hid-client: only load for matching devices
HID: intel-ish-hid: fw-loader: only load for matching devices
HID: intel-ish-hid: use constants for modaliases
HID: intel-ish-hid: add support for MODULE_DEVICE_TABLE()
If the xenstore page hasn't been allocated properly, reading the value
of the related hvm_param (HVM_PARAM_STORE_PFN) won't actually return
error. Instead, it will succeed and return zero. Instead of attempting
to xen_remap a bad guest physical address, detect this condition and
return early.
Note that although a guest physical address of zero for
HVM_PARAM_STORE_PFN is theoretically possible, it is not a good choice
and zero has never been validly used in that capacity.
Also recognize all bits set as an invalid value.
For 32-bit Linux, any pfn above ULONG_MAX would get truncated. Pfns
above ULONG_MAX should never be passed by the Xen tools to HVM guests
anyway, so check for this condition and return early.
Evan Green [Fri, 29 Oct 2021 19:24:22 +0000 (12:24 -0700)]
PM: hibernate: Fix snapshot partial write lengths
snapshot_write() is inappropriately limiting the amount of data that can
be written in cases where a partial page has already been written. For
example, one would expect to be able to write 1 byte, then 4095 bytes to
the snapshot device, and have both of those complete fully (since now
we're aligned to a page again). But what ends up happening is we write 1
byte, then 4094/4095 bytes complete successfully.
The reason is that simple_write_to_buffer()'s second argument is the
total size of the buffer, not the size of the buffer minus the offset.
Since simple_write_to_buffer() accounts for the offset in its
implementation, snapshot_write() can just pass the full page size
directly down.
PM: hibernate: use correct mode for swsusp_close()
Commit 39fbef4b0f77 ("PM: hibernate: Get block device exclusively in
swsusp_check()") changed the opening mode of the block device to
(FMODE_READ | FMODE_EXCL).
In the corresponding calls to swsusp_close(), the mode is still just
FMODE_READ which triggers the warning in blkdev_flush_mapping() on
resume from hibernate.
So, use the mode (FMODE_READ | FMODE_EXCL) also when closing the
device.
Fixes: 39fbef4b0f77 ("PM: hibernate: Get block device exclusively in swsusp_check()") Signed-off-by: Thomas Zeitlhofer <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
Kumar Thangavel [Mon, 22 Nov 2021 16:38:18 +0000 (22:08 +0530)]
net/ncsi : Add payload to be 32-bit aligned to fix dropped packets
Update NC-SI command handler (both standard and OEM) to take into
account of payload paddings in allocating skb (in case of payload
size is not 32-bit aligned).
The checksum field follows payload field, without taking payload
padding into account can cause checksum being truncated, leading to
dropped packets.
Mark Rutland [Tue, 23 Nov 2021 11:40:47 +0000 (11:40 +0000)]
sched/scs: Reset task stack state in bringup_cpu()
To hot unplug a CPU, the idle task on that CPU calls a few layers of C
code before finally leaving the kernel. When KASAN is in use, poisoned
shadow is left around for each of the active stack frames, and when
shadow call stacks are in use. When shadow call stacks (SCS) are in use
the task's saved SCS SP is left pointing at an arbitrary point within
the task's shadow call stack.
When a CPU is offlined than onlined back into the kernel, this stale
state can adversely affect execution. Stale KASAN shadow can alias new
stackframes and result in bogus KASAN warnings. A stale SCS SP is
effectively a memory leak, and prevents a portion of the shadow call
stack being used. Across a number of hotplug cycles the idle task's
entire shadow call stack can become unusable.
We previously fixed the KASAN issue in commit:
e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug")
... by removing any stale KASAN stack poison immediately prior to
onlining a CPU.
Subsequently in commit:
f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")
... the refactoring left the KASAN and SCS cleanup in one-time idle
thread initialization code rather than something invoked prior to each
CPU being onlined, breaking both as above.
We fixed SCS (but not KASAN) in commit:
63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit")
... but as this runs in the context of the idle task being offlined it's
potentially fragile.
To fix these consistently and more robustly, reset the SCS SP and KASAN
shadow of a CPU's idle task immediately before we online that CPU in
bringup_cpu(). This ensures the idle task always has a consistent state
when it is running, and removes the need to so so when exiting an idle
task.
Whenever any thread is created, dup_task_struct() will give the task a
stack which is free of KASAN shadow, and initialize the task's SCS SP,
so there's no need to specially initialize either for idle thread within
init_idle(), as this was only necessary to handle hotplug cycles.
Borislav Petkov [Tue, 23 Nov 2021 07:04:34 +0000 (08:04 +0100)]
x86/boot: Mark prepare_command_line() __init
Fix:
WARNING: modpost: vmlinux.o(.text.unlikely+0x64d0): Section mismatch in reference \
from the function prepare_command_line() to the variable .init.data:command_line
The function prepare_command_line() references
the variable __initdata command_line.
This is often because prepare_command_line lacks a __initdata
annotation or the annotation of command_line is wrong.
Apparently some toolchains do different inlining decisions.
Christophe Leroy [Thu, 18 Nov 2021 09:39:53 +0000 (10:39 +0100)]
powerpc/32: Fix hardlockup on vmap stack overflow
Since the commit c118c7303ad5 ("powerpc/32: Fix vmap stack - Do not
activate MMU before reading task struct") a vmap stack overflow
results in a hard lockup. This is because emergency_ctx is still
addressed with its virtual address allthough data MMU is not active
anymore at that time.
The POWER9 ERAT flush instruction is a SLBIA with IH=7, which is a
reserved value on POWER7/8. On POWER8 this invalidates the SLB entries
above index 0, similarly to SLBIA IH=0.
If the SLB entries are invalidated, and then the guest is bypassed, the
host SLB does not get re-loaded, so the bolted entries above 0 will be
lost. This can result in kernel stack access causing a SLB fault.
Kernel stack access causing a SLB fault was responsible for the infamous
mega bug (search "Fix SLB reload bug"). Although since commit 48e7b7695745 ("powerpc/64s/hash: Convert SLB miss handlers to C") that
starts using the kernel stack in the SLB miss handler, it might only
result in an infinite loop of SLB faults. In any case it's a bug.
Fix this by only executing the instruction on >= POWER9 where IH=7 is
defined not to invalidate the SLB. POWER7/8 don't require this ERAT
flush.
The put_user() in schedule_tail() can get stuck in a livelock, similar
to a problem recently fixed on riscv in commit:
285a76bb2cf51b0c ("riscv: evaluate put_user() arg before enabling user access")
In __raw_put_user() we have a critical section between
uaccess_ttbr0_enable() and uaccess_ttbr0_disable() where we cannot
safely call into the scheduler without having taken an exception, as
schedule() and other scheduling functions will not save/restore the
TTBR0 state. If either of the `x` or `ptr` arguments to __raw_put_user()
contain a blocking call, we may call into the scheduler within the
critical section. This can result in two problems:
1) The access within the critical section will occur without the
required TTBR0 tables installed. This will fault, and where the
required tables permit access, the access will be retried without the
required tables, resulting in a livelock.
2) When TTBR0 SW PAN is in use, check_and_switch_context() does not
modify TTBR0, leaving a stale value installed. The mappings of the
blocked task will erroneously be accessible to regular accesses in
the context of the new task. Additionally, if the tables are
subsequently freed, local TLB maintenance required to reuse the ASID
may be lost, potentially resulting in TLB corruption (e.g. in the
presence of CnP).
The same issue exists for __raw_get_user() in the critical section
between uaccess_ttbr0_enable() and uaccess_ttbr0_disable().
A similar issue exists for __get_kernel_nofault() and
__put_kernel_nofault() for the critical section between
__uaccess_enable_tco_async() and __uaccess_disable_tco_async(), as the
TCO state is not context-switched by direct calls into the scheduler.
Here the TCO state may be lost from the context of the current task,
resulting in unexpected asynchronous tag check faults. It may also be
leaked to another task, suppressing expected tag check faults.
To fix all of these cases, we must ensure that we do not directly call
into the scheduler in their respective critical sections. This patch
reworks __raw_put_user(), __raw_get_user(), __get_kernel_nofault(), and
__put_kernel_nofault(), ensuring that parameters are evaluated outside
of the critical sections. To make this requirement clear, comments are
added describing the problem, and line spaces added to separate the
critical sections from other portions of the macros.
For __raw_get_user() and __raw_put_user() the `err` parameter is
conditionally assigned to, and we must currently evaluate this in the
critical section. This behaviour is relied upon by the signal code,
which uses chains of put_user_error() and get_user_error(), checking the
return value at the end. In all cases, the `err` parameter is a plain
int rather than a more complex expression with a blocking call, so this
is safe.
In future we should try to clean up the `err` usage to remove the
potential for this to be a problem.
Aside from the changes to time of evaluation, there should be no
functional change as a result of this patch.
Linus Torvalds [Tue, 23 Nov 2021 21:59:54 +0000 (13:59 -0800)]
Merge tag 'selinux-pr-20211123' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux
Pull SELinux fix from Paul Moore:
"A fix to make sure things are handled correctly when an allocation
fails"
* tag 'selinux-pr-20211123' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux:
selinux: fix NULL-pointer dereference when hashtab allocation fails
Juergen Gross [Fri, 22 Oct 2021 06:47:56 +0000 (08:47 +0200)]
xen: add "not_essential" flag to struct xenbus_driver
When booting the xenbus driver will wait for PV devices to have
connected to their backends before continuing. The timeout is different
between essential and non-essential devices.
Non-essential devices are identified by their nodenames directly in the
xenbus driver, which requires to update this list in case a new device
type being non-essential is added (this was missed for several types
in the past).
In order to avoid this problem, add a "not_essential" flag to struct
xenbus_driver which can be set to "true" by the respective frontend.
Set this flag for the frontends currently regarded to be not essential
(vkbs and vfb) and use it for testing in the xenbus driver.
Mohammed Gamal [Fri, 19 Nov 2021 11:29:00 +0000 (12:29 +0100)]
drm/hyperv: Fix device removal on Gen1 VMs
The Hyper-V DRM driver tries to free MMIO region on removing
the device regardless of VM type, while Gen1 VMs don't use MMIO
and hence causing the kernel to crash on a NULL pointer dereference.
Fix this by making deallocating MMIO only on Gen2 machines and implement
removal for Gen1
Sakari Ailus [Wed, 17 Nov 2021 18:07:34 +0000 (20:07 +0200)]
ACPI: Get acpi_device's parent from the parent field
Printk modifier %pfw is used to print the full path of the device name.
This is obtained device by device until a device no longer has a parent.
On ACPI getting the parent fwnode is done by calling acpi_get_parent()
which tries to down() a semaphore. But local IRQs are now disabled in
vprintk_store() before the mutex is acquired. This is obviously a problem.
Luckily struct device, embedded in struct acpi_device, has a parent field
already. Use that field to get the parent instead of relying on
acpi_get_parent().
Fixes: 3bd32d6a2ee6 ("lib/vsprintf: Add %pfw conversion specifier for printing fwnode names") Cc: 5.5+ <[email protected]> # 5.5+ Signed-off-by: Sakari Ailus <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
Linus Torvalds [Tue, 23 Nov 2021 17:10:08 +0000 (09:10 -0800)]
Merge tag 'sound-5.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A lot of small changes at this time.
There are many ASoC fixes, and the majority of them are new machine
quirks for Intel platforms, as well as the device-specific fixes for
Mediatek and Qualcomm.
In addition, a regression fix for USB-audio and a few more HD- and
USB-audio quirks are found here"
* tag 'sound-5.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (41 commits)
ALSA: intel-dsp-config: add quirk for JSL devices based on ES8336 codec
ALSA: usb-audio: Don't start stream for capture at prepare
ALSA: usb-audio: Switch back to non-latency mode at a later point
ALSA: ctxfi: Fix out-of-range access
ALSA: hda/realtek: Fix LED on HP ProBook 435 G7
ASoC: stm32: i2s: fix 32 bits channel length without mclk
ASoC: codecs: lpass-rx-macro: fix HPHR setting CLSH mask
ASoC: codecs: wcd934x: return error code correctly from hw_params
ASoC: codecs: wcd938x: fix volatile register range
ASoC: topology: Add missing rwsem around snd_ctl_remove() calls
ASoC: qdsp6: q6routing: validate port id before setting up route
ASoC: qdsp6: q6adm: improve error reporting
ASoC: qdsp6: q6asm: fix q6asm_dai_prepare error handling
ASoC: qdsp6: q6routing: Conditionally reset FrontEnd Mixer
ASoC: qdsp6: qdsp6: q6prm: handle clk disable correctly
ASoC: wm_adsp: wm_adsp_control_add() error: uninitialized symbol 'ret'
ALSA: cmipci: Drop stale variable assignment
ALSA: hda/realtek: Add quirk for ASRock NUC Box 1100
ASoC: rsnd: fixup DMAEngine API
ASoC: SOF: build compression interface into snd_sof.ko
...
Klaus Jensen [Wed, 10 Nov 2021 09:19:06 +0000 (10:19 +0100)]
nvme: fix write zeroes pi
Write Zeroes sets PRACT when block integrity is enabled (as it should),
but neglects to also set the reftag which is expected by reads. This
causes protection errors on reads.
Fix this by setting the reftag for type 1 and 2 (for type 3, reads will
not check the reftag).
Enzo Matsumiya [Sat, 6 Nov 2021 02:08:57 +0000 (23:08 -0300)]
nvme-pci: add NO APST quirk for Kioxia device
This particular Kioxia device times out and aborts I/O during any load,
but it's more easily observable with discards (fstrim).
The device gets to a state that is also not possible to use
"nvme set-feature" to disable APST.
Booting with nvme_core.default_ps_max_latency=0 solves the issue.
We had a dozen or so of these devices behaving this same way in
customer environments.
Varun Prakash [Tue, 23 Nov 2021 10:58:56 +0000 (16:28 +0530)]
nvme-tcp: validate R2T PDU in nvme_tcp_handle_r2t()
If maxh2cdata < r2t_length then driver will form multiple
H2CData PDUs, validate R2T PDU in nvme_tcp_handle_r2t() to
reuse nvme_tcp_setup_h2c_data_pdu().
Also set req->state to NVME_TCP_SEND_H2C_PDU in
nvme_tcp_setup_h2c_data_pdu().
Varun Prakash [Mon, 22 Nov 2021 10:08:41 +0000 (15:38 +0530)]
nvmet-tcp: fix incomplete data digest send
Current nvmet_try_send_ddgst() code does not check whether
all data digest bytes are transmitted, fix this by returning
-EAGAIN if all data digest bytes are not transmitted.
Sets the freed pointers to NULL, it will be useful
when destroying the queues to understand if the commands'
buffers have been released already or not.
nvmet-tcp: fix a race condition between release_queue and io_work
If the initiator executes a reset controller operation while
performing I/O, the target kernel will crash because of a race condition
between release_queue and io_work;
nvmet_tcp_uninit_data_in_cmds() may be executed while io_work
is running, calling flush_work() was not sufficient to
prevent this because io_work could requeue itself.
Fix this bug by using cancel_work_sync() to prevent io_work
from requeuing itself and set rcv_state to NVMET_TCP_RECV_ERR to
make sure we don't receive any more data from the socket.
Shyam Prasad N [Fri, 19 Nov 2021 13:04:11 +0000 (13:04 +0000)]
cifs: populate server_hostname for extra channels
Recently, a new field got added to the smb3_fs_context struct
named server_hostname. While creating extra channels, pick up
this field from primary channel.
Shyam Prasad N [Sun, 21 Nov 2021 16:45:44 +0000 (16:45 +0000)]
cifs: nosharesock should be set on new server
Recent fix to maintain a nosharesock state on the
server struct caused a regression. It updated this
field in the old tcp session, and not the new one.
This caused the multichannel scenario to misbehave.
Fixes: c9f1c19cf7c5 (cifs: nosharesock should not share socket with future sessions) Signed-off-by: Shyam Prasad N <[email protected]> Reviewed-by: Paulo Alcantara (SUSE) <[email protected]> Signed-off-by: Steve French <[email protected]>
cpufreq: intel_pstate: ITMT support for overclocked system
On systems with overclocking enabled, CPPC Highest Performance can be
hard coded to 0xff. In this case even if we have cores with different
highest performance, ITMT can't be enabled as the current implementation
depends on CPPC Highest Performance.
On such systems we can use MSR_HWP_CAPABILITIES maximum performance field
when CPPC.Highest Performance is 0xff.
Due to legacy reasons, we can't solely depend on MSR_HWP_CAPABILITIES as
in some older systems CPPC Highest Performance is the only way to identify
different performing cores.
Mathias Nyman [Tue, 23 Nov 2021 10:16:56 +0000 (12:16 +0200)]
usb: hub: Fix locking issues with address0_mutex
Fix the circular lock dependency and unbalanced unlock of addess0_mutex
introduced when fixing an address0_mutex enumeration retry race in commit ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race")
Make sure locking order between port_dev->status_lock and address0_mutex
is correct, and that address0_mutex is not unlocked in hub_port_connect
"done:" codepath which may be reached without locking address0_mutex
cpufreq: intel_pstate: Fix active mode offline/online EPP handling
After commit 4adcf2e5829f ("cpufreq: intel_pstate: Add ->offline and
->online callbacks") the EPP value set by the "performance" scaling
algorithm in the active mode is not restored after an offline/online
cycle which replaces it with the saved EPP value coming from user
space.
Address this issue by forcing intel_pstate_hwp_set() to set a new
EPP value when it runs first time after online.
Adamos Ttofari [Fri, 12 Nov 2021 09:16:57 +0000 (09:16 +0000)]
cpufreq: intel_pstate: Add Ice Lake server to out-of-band IDs
Commit fbdc21e9b038 ("cpufreq: intel_pstate: Add Icelake servers
support in no-HWP mode") enabled the use of Intel P-State driver
for Ice Lake servers.
But it doesn't cover the case when OS can't control P-States.
Therefore, for Ice Lake server, if MSR_MISC_PWR_MGMT bits 8 or 18
are enabled, then the Intel P-State driver should exit as OS can't
control P-States.
Fixes: fbdc21e9b038 ("cpufreq: intel_pstate: Add Icelake servers support in no-HWP mode") Signed-off-by: Adamos Ttofari <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
Marek Behún [Mon, 22 Nov 2021 20:08:34 +0000 (21:08 +0100)]
net: marvell: mvpp2: increase MTU limit when XDP enabled
Currently mvpp2_xdp_setup won't allow attaching XDP program if
mtu > ETH_DATA_LEN (1500).
The mvpp2_change_mtu on the other hand checks whether
MVPP2_RX_PKT_SIZE(mtu) > MVPP2_BM_LONG_PKT_SIZE.
These two checks are semantically different.
Moreover this limit can be increased to MVPP2_MAX_RX_BUF_SIZE, since in
mvpp2_rx we have
xdp.data = data + MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM;
xdp.frame_sz = PAGE_SIZE;
Change the checks to check whether
mtu > MVPP2_MAX_RX_BUF_SIZE
Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Signed-off-by: Marek Behún <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Alex Elder [Tue, 23 Nov 2021 01:16:40 +0000 (19:16 -0600)]
net: ipa: kill ipa_cmd_pipeline_clear()
Calling ipa_cmd_pipeline_clear() after stopping the channel
underlying the AP<-modem RX endpoint can lead to a deadlock.
This occurs in the ->runtime_suspend device power operation for the
IPA driver. While this callback is in progress, any other requests
for power will block until the callback returns.
Stopping the AP<-modem RX channel does not prevent the modem from
sending another packet to this endpoint. If a packet arrives for an
RX channel when the channel is stopped, an SUSPEND IPA interrupt
condition will be pending. Handling an IPA interrupt requires
power, so ipa_isr_thread() calls pm_runtime_get_sync() first thing.
The problem occurs because a "pipeline clear" command will not
complete while such a SUSPEND interrupt condition exists. So the
SUSPEND IPA interrupt handler won't proceed until it gets power;
that won't happen until the ->runtime_suspend callback (and its
"pipeline clear" command) completes; and that can't happen while
the SUSPEND interrupt condition exists.
It turns out that in this case there is no need to use the "pipeline
clear" command. There are scenarios in which clearing the pipeline
is required while suspending, but those are not (yet) supported
upstream. So a simple fix, avoiding the potential deadlock, is to
stop calling ipa_cmd_pipeline_clear() in ipa_endpoint_suspend().
This removes the only user of ipa_cmd_pipeline_clear(), so get rid
of that function. It can be restored again whenever it's needed.
This is basically a manual revert along with an explanation for
commit 6cb63ea6a39ea ("net: ipa: introduce ipa_cmd_tag_process()").
Fixes: 6cb63ea6a39ea ("net: ipa: introduce ipa_cmd_tag_process()") Signed-off-by: Alex Elder <[email protected]> Signed-off-by: David S. Miller <[email protected]>
The driver should not be connecting and disconnecting the PHY when the
device is opened and closed, it should be stopping and starting the PHY. The
phy should be connected as part of binding and disconnected during
unbinding.
As this results in the PHY not being reset during open, link speed, etc.
settings set prior to the link coming up are now not being lost.
It is necessary for phy_stop() to only be called when the phydev still
exists (resolving the above stack trace). When unbinding, ".unbind" will be
called prior to ".stop", with phy_disconnect() already having called
phy_stop() before the phydev becomes inaccessible.
Zheyu Ma [Tue, 23 Nov 2021 02:21:50 +0000 (02:21 +0000)]
net: chelsio: cxgb4vf: Fix an error code in cxgb4vf_pci_probe()
During the process of driver probing, probe function should return < 0
for failure, otherwise kernel will treat value == 0 as success.
Therefore, we should set err to -EINVAL when
adapter->registered_device_map is NULL. Otherwise kernel will assume
that driver has been successfully probed and will cause unexpected
errors.
David S. Miller [Tue, 23 Nov 2021 12:10:07 +0000 (12:10 +0000)]
Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2021-11-22
Maciej Fijalkowski says:
Here are the two fixes for issues around ethtool's set_channels()
callback for ice driver. Both are related to XDP resources. First one
corrects the size of vsi->txq_map that is used to track the usage of Tx
resources and the second one prevents the wrong refcounting of bpf_prog.
====================
David S. Miller [Tue, 23 Nov 2021 12:06:40 +0000 (12:06 +0000)]
Merge branch 'ipa-fixes'
Alex Elder says:
====================
net: ipa: prevent shutdown during setup
The setup phase of the IPA driver occurs in one of two ways.
Normally, it is done directly by the main driver probe function.
But some systems (those having a "modem-init" DTS property) don't
start setup until an SMP2P interrupt (sent by the modem) arrives.
Because it isn't performed by the probe function, setup on
"modem-init" systems could be underway at the time a driver
remove (or shutdown) request arrives (or vice-versa). This
situation can lead to hardware state not being cleaned up
properly.
This series addresses this problem by having the driver remove
function disable the setup interrupt. A consequence of this is
that setup will complete if it is underway when the remove function
is called.
So now, when removing the driver, setup:
- will have already completed;
- is underway, and will complete before proceeding; or
- will not have begun (and will not occur).
====================
Alex Elder [Tue, 23 Nov 2021 00:15:55 +0000 (18:15 -0600)]
net: ipa: separate disabling setup from modem stop
The IPA setup_complete flag is set at the end of ipa_setup(), when
the setup phase of initialization has completed successfully. This
occurs as part of driver probe processing, or (if "modem-init" is
specified in the DTS file) it is triggered by the "ipa-setup-ready"
SMP2P interrupt generated by the modem.
In the latter case, it's possible for driver shutdown (or remove) to
begin while setup processing is underway, and this can't be allowed.
The problem is that the setup_complete flag is not adequate to signal
that setup is underway.
If setup_complete is set, it will never be un-set, so that case is
not a problem. But if setup_complete is false, there's a chance
setup is underway.
Because setup is triggered by an interrupt on a "modem-init" system,
there is a simple way to ensure the value of setup_complete is safe
to read. The threaded handler--if it is executing--will complete as
part of a request to disable the "ipa-modem-ready" interrupt. This
means that ipa_setup() (which is called from the handler) will run
to completion if it was underway, or will never be called otherwise.
The request to disable the "ipa-setup-ready" interrupt is currently
made within ipa_modem_stop(). Instead, disable the interrupt
outside that function in the two places it's called. In the case of
ipa_remove(), this ensures the setup_complete flag is safe to read
before we read it.
Rename ipa_smp2p_disable() to be ipa_smp2p_irq_disable_setup(), to be
more specific about its effect.
Fixes: 530f9216a953 ("soc: qcom: ipa: AP/modem communications") Signed-off-by: Alex Elder <[email protected]> Signed-off-by: David S. Miller <[email protected]>
We currently maintain a "disabled" Boolean flag to determine whether
the "ipa-setup-ready" SMP2P IRQ handler does anything. That flag
must be accessed under protection of a mutex.
Instead, disable the SMP2P interrupt when requested, which prevents
the interrupt handler from ever being called. More importantly, it
synchronizes a thread disabling the interrupt with the completion of
the interrupt handler in case they run concurrently.
Use the IPA setup_complete flag rather than the disabled flag in the
handler to determine whether to ignore any interrupts arriving after
the first.
Rename the "disabled" flag to be "setup_disabled", to be specific
about its purpose.
Fixes: 530f9216a953 ("soc: qcom: ipa: AP/modem communications") Signed-off-by: Alex Elder <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Miquel Raynal [Mon, 15 Nov 2021 11:08:18 +0000 (12:08 +0100)]
docs: i2c: smbus-protocol: mention the repeated start condition
Sr is a repeated start, it is used in both I2C and SMBus protocols.
Provide its description and replace start ("S") conditions with repeated
start ("Sr") conditions when relevant. This allows the documentation to
match the SMBus specification available at [1].
David S. Miller [Tue, 23 Nov 2021 11:46:18 +0000 (11:46 +0000)]
Merge branch 'mlxsw-fixes'
Ido Schimmel says:
====================
mlxsw: Two small fixes
Patch #1 fixes a recent regression that prevents the driver from loading
with old firmware versions.
Patch #2 protects the driver from a NULL pointer dereference when
working on top of a buggy firmware. This was never observed in an actual
system, only on top of an emulator during development.
====================
Amit Cohen [Tue, 23 Nov 2021 07:52:56 +0000 (09:52 +0200)]
mlxsw: spectrum: Protect driver from buggy firmware
When processing port up/down events generated by the device's firmware,
the driver protects itself from events reported for non-existent local
ports, but not the CPU port (local port 0), which exists, but lacks a
netdev.
This can result in a NULL pointer dereference when calling
netif_carrier_{on,off}().
Fix this by bailing early when processing an event reported for the CPU
port. Problem was only observed when running on top of a buggy emulator.
Fixes: 28b1987ef506 ("mlxsw: spectrum: Register CPU port with devlink") Signed-off-by: Amit Cohen <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Tony Lu [Tue, 23 Nov 2021 08:25:18 +0000 (16:25 +0800)]
net/smc: Ensure the active closing peer first closes clcsock
The side that actively closed socket, it's clcsock doesn't enter
TIME_WAIT state, but the passive side does it. It should show the same
behavior as TCP sockets.
Consider this, when client actively closes the socket, the clcsock in
server enters TIME_WAIT state, which means the address is occupied and
won't be reused before TIME_WAIT dismissing. If we restarted server, the
service would be unavailable for a long time.
To solve this issue, shutdown the clcsock in [A], perform the TCP active
close progress first, before the passive closed side closing it. So that
the actively closed side enters TIME_WAIT, not the passive one.
Client | Server
close() // client actively close |
smc_release() |
smc_close_active() // PEERCLOSEWAIT1 |
smc_close_final() // abort or closed = 1|
smc_cdc_get_slot_and_msg_send() |
[A] |
|smc_cdc_msg_recv_action() // ACTIVE
| queue_work(smc_close_wq, &conn->close_work)
| smc_close_passive_work() // PROCESSABORT or APPCLOSEWAIT1
| smc_close_passive_abort_received() // only in abort
|
|close() // server recv zero, close
| smc_release() // PROCESSABORT or APPCLOSEWAIT1
| smc_close_active()
| smc_close_abort() or smc_close_final() // CLOSED
| smc_cdc_get_slot_and_msg_send() // abort or closed = 1
smc_cdc_msg_recv_action() | smc_clcsock_release()
queue_work(smc_close_wq, &conn->close_work) | sock_release(tcp) // actively close clc, enter TIME_WAIT
smc_close_passive_work() // PEERCLOSEWAIT1 | smc_conn_free()
smc_close_passive_abort_received() // CLOSED|
smc_conn_free() |
smc_clcsock_release() |
sock_release(tcp) // passive close clc |
Tony Lu [Tue, 23 Nov 2021 08:25:16 +0000 (16:25 +0800)]
net/smc: Clean up local struct sock variables
There remains some variables to replace with local struct sock. So clean
them up all.
Fixes: 3163c5071f25 ("net/smc: use local struct sock variables consistently") Signed-off-by: Tony Lu <[email protected]> Reviewed-by: Wen Gu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
net: nexthop: fix null pointer dereference when IPv6 is not enabled
When we try to add an IPv6 nexthop and IPv6 is not enabled
(!CONFIG_IPV6) we'll hit a NULL pointer dereference[1] in the error path
of nh_create_ipv6() due to calling ipv6_stub->fib6_nh_release. The bug
has been present since the beginning of IPv6 nexthop gateway support.
Commit 1aefd3de7bc6 ("ipv6: Add fib6_nh_init and release to stubs") tells
us that only fib6_nh_init has a dummy stub because fib6_nh_release should
not be called if fib6_nh_init returns an error, but the commit below added
a call to ipv6_stub->fib6_nh_release in its error path. To fix it return
the dummy stub's -EAFNOSUPPORT error directly without calling
ipv6_stub->fib6_nh_release in nh_create_ipv6()'s error path.
Jon Hunter [Mon, 15 Nov 2021 11:38:13 +0000 (11:38 +0000)]
mmc: spi: Add device-tree SPI IDs
Commit 5fa6863ba692 ("spi: Check we have a spi_device_id for each DT
compatible") added a test to check that every SPI driver has a
spi_device_id for each DT compatiable string defined by the driver
and warns if the spi_device_id is missing. The spi_device_id is
missing for the MMC SPI driver and the following warning is now seen.
WARNING KERN SPI driver mmc_spi has no spi_device_id for mmc-spi-slot
projects / linux.git / log