| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When testing a kernel with commit a5905d6af492 ("KVM: arm64:
Allow SMCCC_ARCH_WORKAROUND_3 to be discovered and migrated")
get-reg-list output
vregs: Number blessed registers: 234
vregs: Number registers: 238
vregs: There are 1 new registers.
Consider adding them to the blessed reg list with the following lines:
KVM_REG_ARM_FW_REG(3),
vregs: PASS
...
That output inspired two changes: 1) add the new register to the
blessed list and 2) explain why "Number registers" is actually four
larger than "Number blessed registers" (on the system used for
testing), even though only one register is being stated as new.
The reason is that some registers are host dependent and they get
filtered out when comparing with the blessed list. The system
used for the test apparently had three filtered registers.
Signed-off-by: Andrew Jones <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
When a slip driver is detaching, the slip_close() will act to
cleanup necessary resources and sl->tty is set to NULL in
slip_close(). Meanwhile, the packet we transmit is blocked,
sl_tx_timeout() will be called. Although slip_close() and
sl_tx_timeout() use sl->lock to synchronize, we don`t judge
whether sl->tty equals to NULL in sl_tx_timeout() and the
null pointer dereference bug will happen.
(Thread 1) | (Thread 2)
| slip_close()
| spin_lock_bh(&sl->lock)
| ...
... | sl->tty = NULL //(1)
sl_tx_timeout() | spin_unlock_bh(&sl->lock)
spin_lock(&sl->lock); |
... | ...
tty_chars_in_buffer(sl->tty)|
if (tty->ops->..) //(2) |
... | synchronize_rcu()
We set NULL to sl->tty in position (1) and dereference sl->tty
in position (2).
This patch adds check in sl_tx_timeout(). If sl->tty equals to
NULL, sl_tx_timeout() will goto out.
Signed-off-by: Duoming Zhou <[email protected]>
Reviewed-by: Jiri Slaby <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Alexei Starovoitov says:
====================
pull-request: bpf 2022-04-06
We've added 8 non-merge commits during the last 8 day(s) which contain
a total of 9 files changed, 139 insertions(+), 36 deletions(-).
The main changes are:
1) rethook related fixes, from Jiri and Masami.
2) Fix the case when tracing bpf prog is attached to struct_ops, from Martin.
3) Support dual-stack sockets in bpf_tcp_check_syncookie, from Maxim.
* https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
bpf: Adjust bpf_tcp_check_syncookie selftest to test dual-stack sockets
bpf: Support dual-stack sockets in bpf_tcp_check_syncookie
bpf: selftests: Test fentry tracing a struct_ops program
bpf: Resolve to prog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT
rethook: Fix to use WRITE_ONCE() for rethook:: Handler
selftests/bpf: Fix warning comparing pointer to 0
bpf: Fix sparse warnings in kprobe_multi_resolve_syms
bpftool: Explicit errno handling in skeletons
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
The megaraid_sas driver supports single LUN for RAID devices. That is LUN
0. All other LUNs are unsupported. When a device scan on a logical target
with invalid LUN number is invoked through sysfs, that target ends up
getting removed.
Add LUN ID validation in the slave destroy function to avoid the target
deletion.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Chandrakanth patil <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The list iterator is always non-NULL so the check 'if (!rgn)' is always
false and the dev_err() is never called. Move the check outside the loop
and determine if 'victim_rgn' is NULL, to fix this bug.
Link: https://lore.kernel.org/r/[email protected]
Fixes: 4b5f49079c52 ("scsi: ufs: ufshpb: L2P map management for HPB read")
Reviewed-by: Daejun Park <[email protected]>
Signed-off-by: Xiaomeng Tong <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
We forgot to call blk_cleanup_disk() when device_add_disk() failed. This
would cause a memory leak of gendisk and sched_tags allocated in
elevator_init_mq()
Reference:https://syzkaller.appspot.com/x/log.txt?x=13b41dcb700000
Reported-and-tested-by: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Wenchao Hao <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Variable dmp is being assigned a value that is never read, the variable is
redundant and can be removed.
Cleans up clang scan build warning:
drivers/message/fusion/mptbase.c:6667:39: warning: Although
the value stored to 'dmp' is used in the enclosing expression,
the value is never actually read from 'dmp' [deadcode.DeadStores]
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The HighPoint RocketRaid 2640 is a low-cost SAS controller based on Marvell
chip. The chip in question was already supported by the kernel, just the
PCI ID of this particular board was missing.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexey Galakhov <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
As such it should be called inside the scsi_device_supports_vpd()
conditional.
Link: https://lore.kernel.org/r/[email protected]
Fixes: e815d36548f0 ("scsi: sd: add concurrent positioning ranges support")
Cc: Damien Le Moal <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Damien Le Moal <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
As part of controller reset operation the driver issues a config request
command. If this command gets times out, then fail the controller reset
operation instead of retrying it.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
This driver doesn't use SCp.ptr to save a SCSI command data pointer which
means "scsi pointer" is a complete misnomer here. Only a few members of
struct scsi_pointer are needed so move those to private command data.
Link: https://lore.kernel.org/r/accf71e293ba3aed6d18c8baeb405de8dfe7c935.1649235939.git.fthain@linux-m68k.org
Cc: Bart Van Assche <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Finn Thain <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Add PCI ID and callbacks to support Intel Meteor Lake (MTL).
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected] # v5.15+
Reviewed-by: Avri Altman <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Adrian Hunter <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The start_addres argument of mpt3sas_check_same_4gb_region() was misnamed
in the function kdoc comment, resulting in the following warning when
compiling with W=1.
drivers/scsi/mpt3sas/mpt3sas_base.c:5728: warning: Function parameter or
member 'start_address' not described in 'mpt3sas_check_same_4gb_region'
drivers/scsi/mpt3sas/mpt3sas_base.c:5728: warning: Excess function
parameter 'reply_pool_start_address' description in
'mpt3sas_check_same_4gb_region'
Fix the argument name in the function kdoc comment to avoid it. While at
it, remove a useless blank line between the kdoc and function code.
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Sreekanth Reddy <[email protected]>
Signed-off-by: Damien Le Moal <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The in_use_bm bitmap of struct sdebug_queue should be accessed under
protection of the qc_lock spinlock. Make sure that this lock is taken
before calling find_first_bit() at the beginning of the function
sdebug_blk_mq_poll().
Link: https://lore.kernel.org/r/[email protected]
Fixes: 3fd07aecb750 ("scsi: scsi_debug: Fix qc_lock use in sdebug_blk_mq_poll()")
Acked-by: Douglas Gilbert <[email protected]>
Signed-off-by: Damien Le Moal <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Pull the remaining commits from 5.18/scsi-queue into fixes.
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Make the width-mm/height-mm panel properties mandatory
to correctly report the panel dimensions to the OS.
Fixes: 2f3468b82db97 ("dt-bindings: display: add bindings for MIPI DBI compatible SPI panels")
Signed-off-by: Marek Vasut <[email protected]>
Cc: Christoph Niedermaier <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Dmitry Osipenko <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Noralf Trønnes <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Robert Foss <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: [email protected]
To: [email protected]
Acked-by: Noralf Trønnes <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Acked-by: Rob Herring <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-fixes-5.18-2022-04-06:
amdgpu:
- VCN 3.0 fixes
- DCN 3.1.5 fix
- Misc display fixes
- GC 10.3 golden register fix
- Suspend fix
- SMU 10 fix
amdkfd:
- Event fix
Signed-off-by: Dave Airlie <[email protected]>
From: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
into drm-fixes
drm/imx: error handling and debug output fixes
Catch an EDID allocation failure in imx-ldb, fix a leaked drm display
mode on DT parsing error in parallel-display, properly remove the
dw_hdmi bridge in case the component_add fails in dw_hdmi-imx, and
fix the IPU clock frequency debug printout in ipu-di.
Signed-off-by: Dave Airlie <[email protected]>
From: Philipp Zabel <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
* drm/panel/ili9341: Fix optional regulator handling
Signed-off-by: Dave Airlie <[email protected]>
From: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-next-5.18-2022-03-25:
amdgpu:
- GFX 10.3.7 fixes
- noretry updates
- VCN fixes
- TMDS fix
- zstate fix for freesync video
- DCN 3.1.5 fix
- Display stack size fix
- Audio fix
- DCN 3.1 pstate fix
- TMZ VCN fix
- APU passthrough fix
- Misc other fixes
amdkfd:
- Error handling fix
- xgmi p2p fix
- HWS VMIDs fix
Signed-off-by: Dave Airlie <[email protected]>
From: Alex Deucher <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In 1448769c9cdb ("random: check for signal_pending() outside of
need_resched() check"), Jann pointed out that we previously were only
checking the TIF_NOTIFY_SIGNAL and TIF_SIGPENDING flags if the process
had TIF_NEED_RESCHED set, which meant in practice, super long reads to
/dev/[u]random would delay signal handling by a long time. I tried this
using the below program, and indeed I wasn't able to interrupt a
/dev/urandom read until after several megabytes had been read. The bug
he fixed has always been there, and so code that reads from /dev/urandom
without checking the return value of read() has mostly worked for a long
time, for most sizes, not just for <= 256.
Maybe it makes sense to keep that code working. The reason it was so
small prior, ignoring the fact that it didn't work anyway, was likely
because /dev/random used to block, and that could happen for pretty
large lengths of time while entropy was gathered. But now, it's just a
chacha20 call, which is extremely fast and is just operating on pure
data, without having to wait for some external event. In that sense,
/dev/[u]random is a lot more like /dev/zero.
Taking a page out of /dev/zero's read_zero() function, it always returns
at least one chunk, and then checks for signals after each chunk. Chunk
sizes there are of length PAGE_SIZE. Let's just copy the same thing for
/dev/[u]random, and check for signals and cond_resched() for every
PAGE_SIZE amount of data. This makes the behavior more consistent with
expectations, and should mitigate the impact of Jann's fix for the
age-old signal check bug.
---- test program ----
#include <unistd.h>
#include <signal.h>
#include <stdio.h>
#include <sys/random.h>
static unsigned char x[~0U];
static void handle(int) { }
int main(int argc, char *argv[])
{
pid_t pid = getpid(), child;
signal(SIGUSR1, handle);
if (!(child = fork())) {
for (;;)
kill(pid, SIGUSR1);
}
pause();
printf("interrupted after reading %zd bytes\n", getrandom(x, sizeof(x), 0));
kill(child, SIGTERM);
return 0;
}
Cc: Jann Horn <[email protected]>
Cc: Theodore Ts'o <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>
|
|
This reverts commit 602946ec2f90d5bd965857753880db29d2d9a1e9.
If CONFIG_HIGHMEM is enabled, no highmem will be added with max_mapnr
set to max_low_pfn, see mem_init():
for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) {
...
free_highmem_page();
}
Now that virt_addr_valid() has been fixed in the previous commit, we can
revert the change to max_mapnr.
Fixes: 602946ec2f90 ("powerpc: Set max_mapnr correctly")
Signed-off-by: Kefeng Wang <[email protected]>
Reviewed-by: Christophe Leroy <[email protected]>
Reported-by: Erhard F. <[email protected]>
[mpe: Update change log to reflect series reordering]
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
mpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000.
Because of the way __pa() works we have:
__pa(0x8000000000000000) == 0, and therefore
virt_to_pfn(0x8000000000000000) == 0, and therefore
virt_addr_valid(0x8000000000000000) == true
Which is wrong, virt_addr_valid() should be false for vmalloc space.
In fact all vmalloc addresses that alias with a valid PFN will return
true from virt_addr_valid(). That can cause bugs with hardened usercopy
as described below by Kefeng Wang:
When running ethtool eth0 on 64-bit Book3E, a BUG occurred:
usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!
kernel BUG at mm/usercopy.c:99
...
usercopy_abort+0x64/0xa0 (unreliable)
__check_heap_object+0x168/0x190
__check_object_size+0x1a0/0x200
dev_ethtool+0x2494/0x2b20
dev_ioctl+0x5d0/0x770
sock_do_ioctl+0xf0/0x1d0
sock_ioctl+0x3ec/0x5a0
__se_sys_ioctl+0xf0/0x160
system_call_exception+0xfc/0x1f0
system_call_common+0xf8/0x200
The code shows below,
data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));
copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))
The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true
on 64-bit Book3E, which leads to the panic.
As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va
and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in
the virt_addr_valid() for 64-bit, also add upper limit check to make
sure the virt is below high_memory.
Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start
of lowmem, high_memory is the upper low virtual address, the check is
suitable for 32-bit, this will fix the issue mentioned in commit
602946ec2f90 ("powerpc: Set max_mapnr correctly") too.
On 32-bit there is a similar problem with high memory, that was fixed in
commit 602946ec2f90 ("powerpc: Set max_mapnr correctly"), but that
commit breaks highmem and needs to be reverted.
We can't easily fix __pa(), we have code that relies on its current
behaviour. So for now add extra checks to virt_addr_valid().
For 64-bit Book3S the extra checks are not necessary, the combination of
virt_to_pfn() and pfn_valid() should yield the correct result, but they
are harmless.
Signed-off-by: Kefeng Wang <[email protected]>
Reviewed-by: Christophe Leroy <[email protected]>
[mpe: Add additional change log detail]
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The Renesas RZ/V2L SoC (a.k.a R9A07G054) has a Bifrost Mali-G31 GPU,
add a compatible string for it.
Signed-off-by: Lad Prabhakar <[email protected]>
Reviewed-by: Biju Das <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
OF framebuffers do not have an underlying device in the Linux
device hierarchy. Do a regular unregister call instead of hot
unplugging such a non-existing device. Fixes a NULL dereference.
An example error message on ppc64le is shown below.
BUG: Kernel NULL pointer dereference on read at 0x00000060
Faulting instruction address: 0xc00000000080dfa4
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[...]
CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1
NIP: c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430
REGS: c000000004132fe0 TRAP: 0300 Not tainted (5.17.0-ae085d7f9365)
MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28228282 XER: 20000000
CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0
GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029
GPR04: 00000000ffffefff c000000004132f90 c000000004132f88 0000000000000000
GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283
GPR12: 0000000000000000 c00000003fffe300 0000000020000000 0000000000000000
GPR16: 0000000000000000 0000000113fc4a40 0000000000000005 0000000113fcfb80
GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0
GPR24: 0000000000000001 00000000000a0000 c008000000db0168 c0000000021f6ec0
GPR28: c0000000016d65a8 c000000004b36460 0000000000000000 c0000000016d64b0
NIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0
[c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable)
[c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150
[c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0
[c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm]
[c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs]
[...]
[c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0
[c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250
The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug
firmware fb devices on forced removal"). Most firmware framebuffers
have an underlying platform device, which can be hot-unplugged
before loading the native graphics driver. OF framebuffers do not
(yet) have that device. Fix the code by unregistering the framebuffer
as before without a hot unplug.
Tested with 5.17 on qemu ppc64le emulation.
Signed-off-by: Thomas Zimmermann <[email protected]>
Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
Reported-by: Sudip Mukherjee <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Tested-by: Sudip Mukherjee <[email protected]>
Cc: Zack Rusin <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: [email protected] # v5.11+
Cc: Helge Deller <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Zheyu Ma <[email protected]>
Cc: Xiyu Yang <[email protected]>
Cc: Zhen Lei <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: [email protected]
Cc: [email protected]
Link: https://lore.kernel.org/all/YkHXO6LGHAN0p1pq@debian/ # [1]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We want our pages not to change while they are being written.
Signed-off-by: Christoph Böhmwalder <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
The bug is here:
idr_remove(&connection->peer_devices, vnr);
If the previous for_each_connection() don't exit early (no goto hit
inside the loop), the iterator 'connection' after the loop will be a
bogus pointer to an invalid structure object containing the HEAD
(&resource->connections). As a result, the use of 'connection' above
will lead to a invalid memory access (including a possible invalid free
as idr_remove could call free_layer).
The original intention should have been to remove all peer_devices,
but the following lines have already done the work. So just remove
this line and the unneeded label, to fix this bug.
Cc: [email protected]
Fixes: c06ece6ba6f1b ("drbd: Turn connection->volumes into connection->peer_devices")
Signed-off-by: Xiaomeng Tong <[email protected]>
Reviewed-by: Christoph Böhmwalder <[email protected]>
Reviewed-by: Lars Ellenberg <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
In get_initial_state, it calls notify_initial_state_done(skb,..) if
cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(),
the skb will be freed by nlmsg_free(skb).
Then get_initial_state will goto out and the freed skb will be used by
return value skb->len, which is a uaf bug.
What's worse, the same problem goes even further: skb can also be
freed in the notify_*_state_change -> notify_*_state calls below.
Thus 4 additional uaf bugs happened.
My patch lets the problem callee functions: notify_initial_state_done
and notify_*_state_change return an error code if errors happen.
So that the error codes could be propagated and the uaf bugs can be avoid.
v2 reports a compilation warning. This v3 fixed this warning and built
successfully in my local environment with no additional warnings.
v2: https://lore.kernel.org/patchwork/patch/1435218/
Fixes: a29728463b254 ("drbd: Backport the "events2" command")
Signed-off-by: Lv Yunlong <[email protected]>
Reviewed-by: Christoph Böhmwalder <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
Trond Myklebust reports an NFSD crash in svc_rdma_sendto(). Further
investigation shows that the crash occurred while NFSD was handling
a deferred request.
This patch addresses two inter-related issues that prevent request
deferral from working correctly for RPC/RDMA requests:
1. Prevent the crash by ensuring that the original
svc_rqst::rq_xprt_ctxt value is available when the request is
revisited. Otherwise svc_rdma_sendto() does not have a Receive
context available with which to construct its reply.
2. Possibly since before commit 71641d99ce03 ("svcrdma: Properly
compute .len and .buflen for received RPC Calls"),
svc_rdma_recvfrom() did not include the transport header in the
returned xdr_buf. There should have been no need for svc_defer()
and friends to save and restore that header, as of that commit.
This issue is addressed in a backport-friendly way by simply
having svc_rdma_recvfrom() set rq_xprt_hlen to zero
unconditionally, just as svc_tcp_recvfrom() does. This enables
svc_deferred_recv() to correctly reconstruct an RPC message
received via RPC/RDMA.
Reported-by: Trond Myklebust <[email protected]>
Link: https://lore.kernel.org/linux-nfs/[email protected]/
Signed-off-by: Chuck Lever <[email protected]>
Cc: <[email protected]>
|
|
snps,dwmac has duplicated name for loongson,ls2k-dwmac and
loongson,ls7a-dwmac.
Signed-off-by: Dongjin Yang <[email protected]>
Fixes: 68277749a013 ("dt-bindings: dwmac: Add bindings for new Loongson SoC and bridge chip")
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/20220404022857epcms1p6e6af1a6a86569f339e50c318abde7d3c@epcms1p6
|
|
kvm_vcpu_release() will call kvm_dirty_ring_free(), freeing
ring->dirty_gfns and setting it to NULL. Afterwards, it calls
kvm_arch_vcpu_destroy().
However, if closing the file descriptor races with KVM_RUN in such away
that vcpu->arch.st.preempted == 0, the following call stack leads to a
NULL pointer dereference in kvm_dirty_run_push():
mark_page_dirty_in_slot+0x192/0x270 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3171
kvm_steal_time_set_preempted arch/x86/kvm/x86.c:4600 [inline]
kvm_arch_vcpu_put+0x34e/0x5b0 arch/x86/kvm/x86.c:4618
vcpu_put+0x1b/0x70 arch/x86/kvm/../../../virt/kvm/kvm_main.c:211
vmx_free_vcpu+0xcb/0x130 arch/x86/kvm/vmx/vmx.c:6985
kvm_arch_vcpu_destroy+0x76/0x290 arch/x86/kvm/x86.c:11219
kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline]
The fix is to release the dirty page ring after kvm_arch_vcpu_destroy
has run.
Reported-by: Qiuhao Li <[email protected]>
Reported-by: Gaoning Pan <[email protected]>
Reported-by: Yongkang Jia <[email protected]>
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
The previous commit fixed support for dual-stack sockets in
bpf_tcp_check_syncookie. This commit adjusts the selftest to verify the
fixed functionality.
Signed-off-by: Maxim Mikityanskiy <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>
Acked-by: Arthur Fabre <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
|
|
bpf_tcp_gen_syncookie looks at the IP version in the IP header and
validates the address family of the socket. It supports IPv4 packets in
AF_INET6 dual-stack sockets.
On the other hand, bpf_tcp_check_syncookie looks only at the address
family of the socket, ignoring the real IP version in headers, and
validates only the packet size. This implementation has some drawbacks:
1. Packets are not validated properly, allowing a BPF program to trick
bpf_tcp_check_syncookie into handling an IPv6 packet on an IPv4
socket.
2. Dual-stack sockets fail the checks on IPv4 packets. IPv4 clients end
up receiving a SYNACK with the cookie, but the following ACK gets
dropped.
This patch fixes these issues by changing the checks in
bpf_tcp_check_syncookie to match the ones in bpf_tcp_gen_syncookie. IP
version from the header is taken into account, and it is validated
properly with address family.
Fixes: 399040847084 ("bpf: add helper to check for a valid SYN cookie")
Signed-off-by: Maxim Mikityanskiy <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>
Reviewed-by: Tariq Toukan <[email protected]>
Acked-by: Arthur Fabre <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
|
|
While there's a comment pointing from dpu_intr_set to dpu_hw_intr_reg
and vice-versa, an array initializer using indices makes it so that the
indices between the enum and array cannot possibly get out of sync even
if they're accidentially ordered wrongly. It is still useful to keep
the comment to be made aware where the register offset mapping resides
while looking at dpu_hw_intr_reg.
Signed-off-by: Marijn Suijten <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Clark <[email protected]>
|
|
kzalloc() is a memory allocation function which can return NULL when
some internal memory errors happen. So it is better to check it to
prevent potential wrong memory access.
Signed-off-by: Xiaoke Wang <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Clark <[email protected]>
|
|
SMU takes clock limits in Mhz units. socclk and fclk were
using 10 khz units in some cases. Switch to Mhz units.
Fixes higher than required SoC clocks.
Fixes: 97cf32996c46d9 ("drm/amd/pm: Removed fixed clock in auto mode DPM")
Reviewed-by: Paul Menzel <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
[Why & How]
Make dcn315 base its clock table off dcfclk rather than fclk.
This change also adds some sanity checking to make sure an
empty pmfw table does not result in invalid dal clocks.
Reviewed-by: Charlene Liu <[email protected]>
Acked-by: Qingqing Zhuo <[email protected]>
Signed-off-by: Dmytro Laktyushkin <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Fixes crash on MST Hub disconnect.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1849
Fixes: ee2698cf79cc ("drm/amd/display: Changed pipe split policy to allow for multi-display pipe split")
Signed-off-by: Benjamin Marty <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
[Why]
Work around to try to wake unresponsive DP sinks may need to be adjusted
for certain sinks.
[How]
Add options to disable work around or adjust time spent trying to wake
unresponsive DPRX.
Tested-by: Daniel Wheeler <[email protected]>
Reviewed-by: Martin Leung <[email protected]>
Acked-by: Tom Chung <[email protected]>
Signed-off-by: Jimmy Kizito <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Remove assert that will hit during odm transition case,
since this is a valid case.
Tested-by: Daniel Wheeler <[email protected]>
Reviewed-by: Alvin Lee <[email protected]>
Acked-by: Tom Chung <[email protected]>
Signed-off-by: Eric Bernstein <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Seems to cause a reboots or hangs on some systems.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1924
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1953
Fixes: daf8de0874ab5b ("drm/amdgpu: always reset the asic in suspend (v2)")
Reviewed-by: Lijo Lazar <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
[Why]
Below general protection fault observed when WebGL Aquarium is run for
longer duration. If drm debug logs are enabled and set to 0x1f then the
issue is observed within 10 minutes of run.
[ 100.717056] general protection fault, probably for non-canonical address 0x2d33302d32323032: 0000 [#1] PREEMPT SMP NOPTI
[ 100.727921] CPU: 3 PID: 1906 Comm: DrmThread Tainted: G W 5.15.30 #12 d726c6a2d6ebe5cf9223931cbca6892f916fe18b
[ 100.754419] RIP: 0010:CalculateSwathWidth+0x1f7/0x44f
[ 100.767109] Code: 00 00 00 f2 42 0f 11 04 f0 48 8b 85 88 00 00 00 f2 42 0f 10 04 f0 48 8b 85 98 00 00 00 f2 42 0f 11 04 f0 48 8b 45 10 0f 57 c0 <f3> 42 0f 2a 04 b0 0f 57 c9 f3 43 0f 2a 0c b4 e8 8c e2 f3 ff 48 8b
[ 100.781269] RSP: 0018:ffffa9230079eeb0 EFLAGS: 00010246
[ 100.812528] RAX: 2d33302d32323032 RBX: 0000000000000500 RCX: 0000000000000000
[ 100.819656] RDX: 0000000000000001 RSI: ffff99deb712c49c RDI: 0000000000000000
[ 100.826781] RBP: ffffa9230079ef50 R08: ffff99deb712460c R09: ffff99deb712462c
[ 100.833907] R10: ffff99deb7124940 R11: ffff99deb7124d70 R12: ffff99deb712ae44
[ 100.841033] R13: 0000000000000001 R14: 0000000000000000 R15: ffffa9230079f0a0
[ 100.848159] FS: 00007af121212640(0000) GS:ffff99deba780000(0000) knlGS:0000000000000000
[ 100.856240] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 100.861980] CR2: 0000209000fe1000 CR3: 000000011b18c000 CR4: 0000000000350ee0
[ 100.869106] Call Trace:
[ 100.871555] <TASK>
[ 100.873655] ? asm_sysvec_reschedule_ipi+0x12/0x20
[ 100.878449] CalculateSwathAndDETConfiguration+0x1a3/0x6dd
[ 100.883937] dml31_ModeSupportAndSystemConfigurationFull+0x2ce4/0x76da
[ 100.890467] ? kallsyms_lookup_buildid+0xc8/0x163
[ 100.895173] ? kallsyms_lookup_buildid+0xc8/0x163
[ 100.899874] ? __sprint_symbol+0x80/0x135
[ 100.903883] ? dm_update_plane_state+0x3f9/0x4d2
[ 100.908500] ? symbol_string+0xb7/0xde
[ 100.912250] ? number+0x145/0x29b
[ 100.915566] ? vsnprintf+0x341/0x5ff
[ 100.919141] ? desc_read_finalized_seq+0x39/0x87
[ 100.923755] ? update_load_avg+0x1b9/0x607
[ 100.927849] ? compute_mst_dsc_configs_for_state+0x7d/0xd5b
[ 100.933416] ? fetch_pipe_params+0xa4d/0xd0c
[ 100.937686] ? dc_fpu_end+0x3d/0xa8
[ 100.941175] dml_get_voltage_level+0x16b/0x180
[ 100.945619] dcn30_internal_validate_bw+0x10e/0x89b
[ 100.950495] ? dcn31_validate_bandwidth+0x68/0x1fc
[ 100.955285] ? resource_build_scaling_params+0x98b/0xb8c
[ 100.960595] ? dcn31_validate_bandwidth+0x68/0x1fc
[ 100.965384] dcn31_validate_bandwidth+0x9a/0x1fc
[ 100.970001] dc_validate_global_state+0x238/0x295
[ 100.974703] amdgpu_dm_atomic_check+0x9c1/0xbce
[ 100.979235] ? _printk+0x59/0x73
[ 100.982467] drm_atomic_check_only+0x403/0x78b
[ 100.986912] drm_mode_atomic_ioctl+0x49b/0x546
[ 100.991358] ? drm_ioctl+0x1c1/0x3b3
[ 100.994936] ? drm_atomic_set_property+0x92a/0x92a
[ 100.999725] drm_ioctl_kernel+0xdc/0x149
[ 101.003648] drm_ioctl+0x27f/0x3b3
[ 101.007051] ? drm_atomic_set_property+0x92a/0x92a
[ 101.011842] amdgpu_drm_ioctl+0x49/0x7d
[ 101.015679] __se_sys_ioctl+0x7c/0xb8
[ 101.015685] do_syscall_64+0x5f/0xb8
[ 101.015690] ? __irq_exit_rcu+0x34/0x96
[How]
It calles populate_dml_pipes which uses doubles to initialize.
Adding FPU protection avoids context switch and probable loss of vba context
as there is potential contention while drm debug logs are enabled.
Signed-off-by: CHANDAN VURDIGERE NATARAJ <[email protected]>
Reviewed-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: "Christian König" <[email protected]>
Cc: "Pan, Xinhui" <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Lee Jones <[email protected]>
Reviewed-by: Felix Kuehling <[email protected]>
Signed-off-by: Felix Kuehling <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
Sync up header and implementation to use the same parameter names
in function amdgpu_ring_init.
ring_size -> max_dw, prio -> hw_prio
Reviewed-by: Guchun Chen <[email protected]>
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Ma Jun <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
gfx10.3.3/gfx10.3.6/gfx10.3.7 shall use 0x1580 address for GCR_GENERAL_CNTL
Acked-by: Prike Liang <[email protected]>
Acked-by: Yifan Zhang <[email protected]>
Reviewed-by: Aaron Liu <[email protected]>
Signed-off-by: Ruili Ji <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
[Why]
comparing pwm bl values (coverted) with user brightness(converted)
levels in commit_tail leads to continuous setting of backlight via dmub
as they don't to match.
This leads overdrive in queuing of commands to DMCU that sometimes lead
to depending on load on DMCU fw:
"[drm:dc_dmub_srv_wait_idle] *ERROR* Error waiting for DMUB idle: status=3"
[How]
Store last successfully set backlight value and compare with it instead
of pwm reads which is not what we should compare with.
Signed-off-by: Shirish S <[email protected]>
Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
[Why]
On resume we do link detection for all non-MST connectors.
MST is handled separately. However the condition for telling
if connector is on mst branch is not enough for mst hub case.
Link detection for mst branch link leads to mst topology reset.
That causes assert in dc_link_allocate_mst_payload()
[How]
Use link type as indicator for mst link.
Reviewed-by: Wayne Lin <[email protected]>
Acked-by: Alex Hung <[email protected]>
Signed-off-by: Roman Li <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
why and how:
causes failure on install on certain machines
Reviewed-by: George Shen <[email protected]>
Acked-by: Alex Hung <[email protected]>
Signed-off-by: Martin Leung <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
[Why]
When waking from low-power states, a DP sink may remain unresponsive to
AUX transactions.
[How]
Try to toggle DPCD SET_POWER register repeatedly (up to a maximum
timeout value) until DP sink becomes responsive.
Reviewed-by: Mustapha Ghaddar <[email protected]>
Acked-by: Alex Hung <[email protected]>
Signed-off-by: Jimmy Kizito <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
[why]
when disable optc, need to clear the underflow status as well.
Reviewed-by: Chris Park <[email protected]>
Acked-by: Alex Hung <[email protected]>
Signed-off-by: Charlene Liu <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|