Mauro (mdrjr) Ribeiro
74cd1ebe6e
Merge tag 'v6.6.25' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.25 stable release
Change-Id: Iaaba50c519931030f0f4fb0789593cb0502df362
2024-05-06 12:17:01 -03:00
Mauro (mdrjr) Ribeiro
e28894640b
Merge tag 'v6.6.24' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.24 stable release
Change-Id: I0cac8f9e820ae5fd81f595abb58658380b1863a4
2024-04-30 10:39:31 -03:00
Mauro (mdrjr) Ribeiro
f4a67984f8
Merge tag 'v6.6.23' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
Linux 6.6.23
Change-Id: Ib9805efbfc2a38efeb0258da492a230693bc0519
2024-04-30 10:39:19 -03:00
Mauro (mdrjr) Ribeiro
e436dc62b8
Merge tag 'v6.6.22' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
Linux 6.6.22
Change-Id: I1ce12f6941e7e65da4a9d0e87ea32bbeeaa36021
2024-04-30 10:39:04 -03:00
Mauro (mdrjr) Ribeiro
963d5ba559
Merge tag 'v6.6.21' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.21 stable release
Change-Id: Icec5a9462593f68d655f25ab58f948886e104e2c
2024-04-30 10:38:54 -03:00
Mauro (mdrjr) Ribeiro
6339762a09
Merge tag 'v6.6.20' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.20 stable release
Change-Id: I231331a23345aea88ba21e312abb5d0cc6bbe0e4
2024-04-30 10:38:37 -03:00
Mauro (mdrjr) Ribeiro
2c433fc7e6
Merge tag 'v6.6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.19 stable release
Change-Id: I0d078bebe1daaccd4cdc209ebf166c8069ac069e
2024-04-30 10:38:28 -03:00
Mauro (mdrjr) Ribeiro
d88ecb202f
Merge tag 'v6.6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.18 stable release
Change-Id: Ia858c852fcc18cc41b5e2e99ce138f7c2d1ed2f3
2024-04-30 10:38:17 -03:00
Mauro (mdrjr) Ribeiro
e0e9afa736
Merge tag 'v6.6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.17 stable release
Change-Id: I46202f4caba1513111a4b578884fc054ea992e56
2024-04-30 10:37:54 -03:00
Mauro (mdrjr) Ribeiro
a0e6fa72d7
Merge tag 'v6.6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.16 stable release
Change-Id: I3d62fd572aade1125a7ee1fc30aa47d0c16fbf3a
2024-04-30 10:37:44 -03:00
Mauro (mdrjr) Ribeiro
5f1fe7a1b2
Merge tag 'v6.6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.15 stable release
Change-Id: I2253b87d8c60958bdfb674df0cd091d39a7caab9
2024-04-30 10:37:25 -03:00
Mauro (mdrjr) Ribeiro
3a4d363441
Merge tag 'v6.6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into odroid-6.6.y
...
This is the 6.6.14 stable release
2024-04-30 10:37:06 -03:00
Mauro (mdrjr) Ribeiro
e352a14cb1
MALI: midgard-T: fix tests build
2024-04-29 12:50:47 -03:00
Mauro (mdrjr) Ribeiro
57762819c5
ODROID-XU4: config: add 1920x720 60hz EDID to the firmware list
2024-04-29 12:50:12 -03:00
Mauro (mdrjr) Ribeiro
663a84d096
firmware/edid: add 1920x720 60hz edid
2024-04-29 12:45:34 -03:00
Greg Kroah-Hartman
e475741af1
Linux 6.6.25
...
Link: https://lore.kernel.org/r/20240403175126.839589571@linuxfoundation.org
Tested-by: Shuah Khan <skhan@linuxfoundation.org >
Tested-by: Ron Economos <re@w6rz.net >
Tested-by: Jon Hunter <jonathanh@nvidia.com >
Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com >
Tested-by: Mark Brown <broonie@kernel.org >
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:07 +02:00
Greg Kroah-Hartman
a99d7274a2
Revert "workqueue.c: Increase workqueue name length"
...
This reverts commit 43a181f8f4 which is
commit 31c89007285d365aa36f71d8fb0701581c770a27 upstream.
The workqueue patches backported to 6.6.y caused some reported
regressions, so revert them for now.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info >
Cc: Tejun Heo <tj@kernel.org >
Cc: Marek Szyprowski <m.szyprowski@samsung.com >
Cc: Nathan Chancellor <nathan@kernel.org >
Cc: Sasha Levin <sashal@kernel.org >
Cc: Audra Mitchell <audra@redhat.com >
Link: https://lore.kernel.org/all/ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:07 +02:00
Greg Kroah-Hartman
d8354f268d
Revert "workqueue: Move pwq->max_active to wq->max_active"
...
This reverts commit 82e098f5be which is
commit a045a272d887575da17ad86d6573e82871b50c27 upstream.
The workqueue patches backported to 6.6.y caused some reported
regressions, so revert them for now.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info >
Cc: Tejun Heo <tj@kernel.org >
Cc: Marek Szyprowski <m.szyprowski@samsung.com >
Cc: Nathan Chancellor <nathan@kernel.org >
Cc: Sasha Levin <sashal@kernel.org >
Cc: Audra Mitchell <audra@redhat.com >
Link: https://lore.kernel.org/all/ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:07 +02:00
Greg Kroah-Hartman
35bf38dd16
Revert "workqueue: Factor out pwq_is_empty()"
...
This reverts commit bad184d26a which is
commit afa87ce85379e2d93863fce595afdb5771a84004 upstream.
The workqueue patches backported to 6.6.y caused some reported
regressions, so revert them for now.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info >
Cc: Tejun Heo <tj@kernel.org >
Cc: Marek Szyprowski <m.szyprowski@samsung.com >
Cc: Nathan Chancellor <nathan@kernel.org >
Cc: Sasha Levin <sashal@kernel.org >
Cc: Audra Mitchell <audra@redhat.com >
Link: https://lore.kernel.org/all/ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:07 +02:00
Greg Kroah-Hartman
957578ec33
Revert "workqueue: Replace pwq_activate_inactive_work() with [__]pwq_activate_work()"
...
This reverts commit 6c592f0bb9 which is
commit 4c6380305d21e36581b451f7337a36c93b64e050 upstream.
The workqueue patches backported to 6.6.y caused some reported
regressions, so revert them for now.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info >
Cc: Tejun Heo <tj@kernel.org >
Cc: Marek Szyprowski <m.szyprowski@samsung.com >
Cc: Nathan Chancellor <nathan@kernel.org >
Cc: Sasha Levin <sashal@kernel.org >
Cc: Audra Mitchell <audra@redhat.com >
Link: https://lore.kernel.org/all/ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:07 +02:00
Greg Kroah-Hartman
5debbff953
Revert "workqueue: Move nr_active handling into helpers"
...
This reverts commit 4023a2d950 which is
commit 1c270b79ce0b8290f146255ea9057243f6dd3c17 upstream.
The workqueue patches backported to 6.6.y caused some reported
regressions, so revert them for now.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info >
Cc: Tejun Heo <tj@kernel.org >
Cc: Marek Szyprowski <m.szyprowski@samsung.com >
Cc: Nathan Chancellor <nathan@kernel.org >
Cc: Sasha Levin <sashal@kernel.org >
Cc: Audra Mitchell <audra@redhat.com >
Link: https://lore.kernel.org/all/ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:07 +02:00
Greg Kroah-Hartman
e3ee73b57a
Revert "workqueue: Make wq_adjust_max_active() round-robin pwqs while activating"
...
This reverts commit 5f99fee6f2 which is
commit qc5404d4e6df6faba1007544b5f4e62c7c14416dd upstream.
The workqueue patches backported to 6.6.y caused some reported
regressions, so revert them for now.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info >
Cc: Tejun Heo <tj@kernel.org >
Cc: Marek Szyprowski <m.szyprowski@samsung.com >
Cc: Nathan Chancellor <nathan@kernel.org >
Cc: Sasha Levin <sashal@kernel.org >
Cc: Audra Mitchell <audra@redhat.com >
Link: https://lore.kernel.org/all/ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:07 +02:00
Greg Kroah-Hartman
f3c11cb27a
Revert "workqueue: RCU protect wq->dfl_pwq and implement accessors for it"
...
This reverts commit bd31fb926d which is
commit 9f66cff212bb3c1cd25996aaa0dfd0c9e9d8baab upstream.
The workqueue patches backported to 6.6.y caused some reported
regressions, so revert them for now.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info >
Cc: Tejun Heo <tj@kernel.org >
Cc: Marek Szyprowski <m.szyprowski@samsung.com >
Cc: Nathan Chancellor <nathan@kernel.org >
Cc: Sasha Levin <sashal@kernel.org >
Cc: Audra Mitchell <audra@redhat.com >
Link: https://lore.kernel.org/all/ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:06 +02:00
Greg Kroah-Hartman
bfb429f370
Revert "workqueue: Introduce struct wq_node_nr_active"
...
This reverts commit b522229a56 which is
commit 91ccc6e7233bb10a9c176aa4cc70d6f432a441a5 upstream.
The workqueue patches backported to 6.6.y caused some reported
regressions, so revert them for now.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info >
Cc: Tejun Heo <tj@kernel.org >
Cc: Marek Szyprowski <m.szyprowski@samsung.com >
Cc: Nathan Chancellor <nathan@kernel.org >
Cc: Sasha Levin <sashal@kernel.org >
Cc: Audra Mitchell <audra@redhat.com >
Link: https://lore.kernel.org/all/ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:06 +02:00
Greg Kroah-Hartman
6741dd3fd3
Revert "workqueue: Implement system-wide nr_active enforcement for unbound workqueues"
...
This reverts commit 5a70baec22 which is
commit 5797b1c18919cd9c289ded7954383e499f729ce0 upstream.
The workqueue patches backported to 6.6.y caused some reported
regressions, so revert them for now.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info >
Cc: Tejun Heo <tj@kernel.org >
Cc: Marek Szyprowski <m.szyprowski@samsung.com >
Cc: Nathan Chancellor <nathan@kernel.org >
Cc: Sasha Levin <sashal@kernel.org >
Cc: Audra Mitchell <audra@redhat.com >
Link: https://lore.kernel.org/all/ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:06 +02:00
Greg Kroah-Hartman
a75ac2693d
Revert "workqueue: Don't call cpumask_test_cpu() with -1 CPU in wq_update_node_max_active()"
...
This reverts commit 7df62b8cca which is
commit 15930da42f8981dc42c19038042947b475b19f47 upstream.
The workqueue patches backported to 6.6.y caused some reported
regressions, so revert them for now.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info >
Cc: Tejun Heo <tj@kernel.org >
Cc: Marek Szyprowski <m.szyprowski@samsung.com >
Cc: Nathan Chancellor <nathan@kernel.org >
Cc: Sasha Levin <sashal@kernel.org >
Cc: Audra Mitchell <audra@redhat.com >
Link: https://lore.kernel.org/all/ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:06 +02:00
Greg Kroah-Hartman
7bff1820bc
Revert "workqueue: Shorten events_freezable_power_efficient name"
...
This reverts commit 8b93439027 which is
commit 8318d6a6362f5903edb4c904a8dd447e59be4ad1 upstream.
The workqueue patches backported to 6.6.y caused some reported
regressions, so revert them for now.
Reported-by: Thorsten Leemhuis <regressions@leemhuis.info >
Cc: Tejun Heo <tj@kernel.org >
Cc: Marek Szyprowski <m.szyprowski@samsung.com >
Cc: Nathan Chancellor <nathan@kernel.org >
Cc: Sasha Levin <sashal@kernel.org >
Cc: Audra Mitchell <audra@redhat.com >
Link: https://lore.kernel.org/all/ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info/
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-04 20:23:06 +02:00
Greg Kroah-Hartman
9467d7a12f
Linux 6.6.24
...
Link: https://lore.kernel.org/r/20240401152547.867452742@linuxfoundation.org
Tested-by: SeongJae Park <sj@kernel.org >
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com >
Tested-by: Shuah Khan <skhan@linuxfoundation.org >
Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com >
Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com >
Tested-by: Ron Economos <re@w6rz.net >
Tested-by: Mark Brown <broonie@kernel.org >
Tested-by: Jon Hunter <jonathanh@nvidia.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:04 +02:00
Vitaly Prosyak
e87e08c94c
drm/amdgpu: fix use-after-free bug
...
commit 22207fd5c80177b860279653d017474b2812af5e upstream.
The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl
to the AMDGPU DRM driver on any ASICs with an invalid address and size.
The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr >.
For example the following code:
static void Syzkaller1(int fd)
{
struct drm_amdgpu_gem_userptr arg;
int ret;
arg.addr = 0xffffffffffff0000;
arg.size = 0x80000000; /*2 Gb*/
arg.flags = 0x7;
ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg);
}
Due to the address and size are not valid there is a failure in
amdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert->
check_shl_overflow, but we even the amdgpu_hmm_register failure we still call
amdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address.
The following stack is below when the issue is reproduced when Kazan is enabled:
[ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
[ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340
[ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80
[ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246
[ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b
[ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260
[ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25
[ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00
[ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260
[ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000
[ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0
[ +0.000010] Call Trace:
[ +0.000006] <TASK>
[ +0.000007] ? show_regs+0x6a/0x80
[ +0.000018] ? __warn+0xa5/0x1b0
[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340
[ +0.000018] ? report_bug+0x24a/0x290
[ +0.000022] ? handle_bug+0x46/0x90
[ +0.000015] ? exc_invalid_op+0x19/0x50
[ +0.000016] ? asm_exc_invalid_op+0x1b/0x20
[ +0.000017] ? kasan_save_stack+0x26/0x50
[ +0.000017] ? mmu_interval_notifier_remove+0x23b/0x340
[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340
[ +0.000019] ? mmu_interval_notifier_remove+0x23b/0x340
[ +0.000020] ? __pfx_mmu_interval_notifier_remove+0x10/0x10
[ +0.000017] ? kasan_save_alloc_info+0x1e/0x30
[ +0.000018] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? __kasan_kmalloc+0xb1/0xc0
[ +0.000018] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __kasan_check_read+0x11/0x20
[ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu]
[ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu]
[ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu]
[ +0.004291] ? do_syscall_64+0x5f/0xe0
[ +0.000023] ? srso_return_thunk+0x5/0x5f
[ +0.000017] drm_gem_object_free+0x3b/0x50 [drm]
[ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu]
[ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[ +0.004270] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? __this_cpu_preempt_check+0x13/0x20
[ +0.000015] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? sysvec_apic_timer_interrupt+0x57/0xc0
[ +0.000020] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
[ +0.000022] ? drm_ioctl_kernel+0x17b/0x1f0 [drm]
[ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm]
[ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm]
[ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm]
[ +0.000489] ? srso_return_thunk+0x5/0x5f
[ +0.000011] ? __kasan_check_write+0x14/0x20
[ +0.000016] drm_ioctl+0x3da/0x730 [drm]
[ +0.000475] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[ +0.004293] ? __pfx_drm_ioctl+0x10/0x10 [drm]
[ +0.000506] ? __pfx_rpm_resume+0x10/0x10
[ +0.000016] ? srso_return_thunk+0x5/0x5f
[ +0.000011] ? __kasan_check_write+0x14/0x20
[ +0.000010] ? srso_return_thunk+0x5/0x5f
[ +0.000011] ? _raw_spin_lock_irqsave+0x99/0x100
[ +0.000015] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ +0.000014] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? srso_return_thunk+0x5/0x5f
[ +0.000011] ? srso_return_thunk+0x5/0x5f
[ +0.000011] ? preempt_count_sub+0x18/0xc0
[ +0.000013] ? srso_return_thunk+0x5/0x5f
[ +0.000010] ? _raw_spin_unlock_irqrestore+0x27/0x50
[ +0.000019] amdgpu_drm_ioctl+0x7e/0xe0 [amdgpu]
[ +0.004272] __x64_sys_ioctl+0xcd/0x110
[ +0.000020] do_syscall_64+0x5f/0xe0
[ +0.000021] entry_SYSCALL_64_after_hwframe+0x6e/0x76
[ +0.000015] RIP: 0033:0x7ff9ed31a94f
[ +0.000012] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
[ +0.000013] RSP: 002b:00007fff25f66790 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ +0.000016] RAX: ffffffffffffffda RBX: 000055b3f7e133e0 RCX: 00007ff9ed31a94f
[ +0.000012] RDX: 000055b3f7e133e0 RSI: 00000000c1186451 RDI: 0000000000000003
[ +0.000010] RBP: 00000000c1186451 R08: 0000000000000000 R09: 0000000000000000
[ +0.000009] R10: 0000000000000008 R11: 0000000000000246 R12: 00007fff25f66ca8
[ +0.000009] R13: 0000000000000003 R14: 000055b3f7021ba8 R15: 00007ff9ed7af040
[ +0.000024] </TASK>
[ +0.000007] ---[ end trace 0000000000000000 ]---
v2: Consolidate any error handling into amdgpu_hmm_register
which applied to kfd_bo also. (Christian)
v3: Improve syntax and comment (Christian)
Cc: Christian Koenig <christian.koenig@amd.com >
Cc: Alex Deucher <alexander.deucher@amd.com >
Cc: Felix Kuehling <felix.kuehling@amd.com >
Cc: Joonkyo Jung <joonkyoj@yonsei.ac.kr >
Cc: Dokyung Song <dokyungs@yonsei.ac.kr >
Cc: <jisoo.jang@yonsei.ac.kr >
Cc: <yw9865@yonsei.ac.kr >
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com >
Reviewed-by: Christian König <christian.koenig@amd.com >
Signed-off-by: Alex Deucher <alexander.deucher@amd.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:04 +02:00
Natanael Copa
3a9569441b
tools/resolve_btfids: fix build with musl libc
...
commit 62248b22d01e96a4d669cde0d7005bd51ebf9e76 upstream.
Include the header that defines u32.
This fixes build of 6.6.23 and 6.1.83 kernels for Alpine Linux, which
uses musl libc. I assume that GNU libc indirecly pulls in linux/types.h.
Fixes: 9707ac4fe2f5 ("tools/resolve_btfids: Refactor set sorting with types from btf_ids.h")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218647
Cc: stable@vger.kernel.org
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org >
Tested-by: Greg Thelen <gthelen@google.com >
Link: https://lore.kernel.org/r/20240328110103.28734-1-ncopa@alpinelinux.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:03 +02:00
Kevin Loughlin
4338e40da8
x86/sev: Skip ROM range scans and validation for SEV-SNP guests
...
commit 0f4a1e80989aca185d955fcd791d7750082044a2 upstream.
SEV-SNP requires encrypted memory to be validated before access.
Because the ROM memory range is not part of the e820 table, it is not
pre-validated by the BIOS. Therefore, if a SEV-SNP guest kernel wishes
to access this range, the guest must first validate the range.
The current SEV-SNP code does indeed scan the ROM range during early
boot and thus attempts to validate the ROM range in probe_roms().
However, this behavior is neither sufficient nor necessary for the
following reasons:
* With regards to sufficiency, if EFI_CONFIG_TABLES are not enabled and
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK is set, the kernel will
attempt to access the memory at SMBIOS_ENTRY_POINT_SCAN_START (which
falls in the ROM range) prior to validation.
For example, Project Oak Stage 0 provides a minimal guest firmware
that currently meets these configuration conditions, meaning guests
booting atop Oak Stage 0 firmware encounter a problematic call chain
during dmi_setup() -> dmi_scan_machine() that results in a crash
during boot if SEV-SNP is enabled.
* With regards to necessity, SEV-SNP guests generally read garbage
(which changes across boots) from the ROM range, meaning these scans
are unnecessary. The guest reads garbage because the legacy ROM range
is unencrypted data but is accessed via an encrypted PMD during early
boot (where the PMD is marked as encrypted due to potentially mapping
actually-encrypted data in other PMD-contained ranges).
In one exceptional case, EISA probing treats the ROM range as
unencrypted data, which is inconsistent with other probing.
Continuing to allow SEV-SNP guests to use garbage and to inconsistently
classify ROM range encryption status can trigger undesirable behavior.
For instance, if garbage bytes appear to be a valid signature, memory
may be unnecessarily reserved for the ROM range. Future code or other
use cases may result in more problematic (arbitrary) behavior that
should be avoided.
While one solution would be to overhaul the early PMD mapping to always
treat the ROM region of the PMD as unencrypted, SEV-SNP guests do not
currently rely on data from the ROM region during early boot (and even
if they did, they would be mostly relying on garbage data anyways).
As a simpler solution, skip the ROM range scans (and the otherwise-
necessary range validation) during SEV-SNP guest early boot. The
potential SEV-SNP guest crash due to lack of ROM range validation is
thus avoided by simply not accessing the ROM range.
In most cases, skip the scans by overriding problematic x86_init
functions during sme_early_init() to SNP-safe variants, which can be
likened to x86_init overrides done for other platforms (ex: Xen); such
overrides also avoid the spread of cc_platform_has() checks throughout
the tree.
In the exceptional EISA case, still use cc_platform_has() for the
simplest change, given (1) checks for guest type (ex: Xen domain status)
are already performed here, and (2) these checks occur in a subsys
initcall instead of an x86_init function.
[ bp: Massage commit message, remove "we"s. ]
Fixes: 9704c07bf9 ("x86/kernel: Validate ROM memory before accessing when SEV-SNP is active")
Signed-off-by: Kevin Loughlin <kevinloughlin@google.com >
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de >
Cc: <stable@kernel.org >
Link: https://lore.kernel.org/r/20240313121546.2964854-1-kevinloughlin@google.com
Signed-off-by: Kevin Loughlin <kevinloughlin@google.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:03 +02:00
Xingui Yang
2048ff503f
scsi: libsas: Fix disk not being scanned in after being removed
...
commit 8e68a458bcf5b5cb9c3624598bae28f08251601f upstream.
As of commit d8649fc1c5 ("scsi: libsas: Do discovery on empty PHY to
update PHY info"), do discovery will send a new SMP_DISCOVER and update
phy->phy_change_count. We found that if the disk is reconnected and phy
change_count changes at this time, the disk scanning process will not be
triggered.
Therefore, call sas_set_ex_phy() to update the PHY info with the results of
the last query. And because the previous phy info will be used when calling
sas_unregister_devs_sas_addr(), sas_unregister_devs_sas_addr() should be
called before sas_set_ex_phy().
Fixes: d8649fc1c5 ("scsi: libsas: Do discovery on empty PHY to update PHY info")
Signed-off-by: Xingui Yang <yangxingui@huawei.com >
Link: https://lore.kernel.org/r/20240307141413.48049-3-yangxingui@huawei.com
Reviewed-by: John Garry <john.g.garry@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:03 +02:00
Xingui Yang
f23db75792
scsi: libsas: Add a helper sas_get_sas_addr_and_dev_type()
...
commit a57345279fd311ba679b8083feb0eec5272c7729 upstream.
Add a helper to get attached_sas_addr and device type from disc_resp.
Suggested-by: John Garry <john.g.garry@oracle.com >
Signed-off-by: Xingui Yang <yangxingui@huawei.com >
Link: https://lore.kernel.org/r/20240307141413.48049-2-yangxingui@huawei.com
Reviewed-by: John Garry <john.g.garry@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:03 +02:00
Muhammad Usama Anjum
76edb986c4
scsi: lpfc: Correct size for wqe for memset()
...
commit 28d41991182c210ec1654f8af2e140ef4cc73f20 upstream.
The wqe is of type lpfc_wqe128. It should be memset with the same type.
Fixes: 6c621a2229 ("scsi: lpfc: Separate NVMET RQ buffer posting from IO resources SGL/iocbq/context")
Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com >
Link: https://lore.kernel.org/r/20240304090649.833953-1-usama.anjum@collabora.com
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com >
Reviewed-by: Justin Tee <justintee8345@gmail.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:03 +02:00
Muhammad Usama Anjum
ac5b18f528
scsi: lpfc: Correct size for cmdwqe/rspwqe for memset()
...
commit 16cc2ba71b9f6440805aef7f92ba0f031f79b765 upstream.
The cmdwqe and rspwqe are of type lpfc_wqe128. They should be memset() with
the same type.
Fixes: 61910d6a52 ("scsi: lpfc: SLI path split: Refactor CT paths")
Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com >
Link: https://lore.kernel.org/r/20240304091119.847060-1-usama.anjum@collabora.com
Reviewed-by: Justin Tee <justin.tee@broadcom.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:03 +02:00
Heikki Krogerus
ff3cdff7c8
usb: dwc3: pci: Drop duplicate ID
...
commit f121531703ae442edc1dde4b56803680628bc5b7 upstream.
Intel Arrow Lake CPU uses the Meteor Lake ID with this
controller (the controller that's part of the Intel Arrow
Lake chipset (PCH) does still have unique PCI ID).
Fixes: de4b5b28c87c ("usb: dwc3: pci: add support for the Intel Arrow Lake-H")
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com >
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com >
Link: https://lore.kernel.org/r/20240312115008.1748637-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:03 +02:00
Dave Hansen
70977e7d5e
Revert "x86/bugs: Use fixed addressing for VERW operand"
...
commit 532a0c57d7ff75e8f07d4e25cba4184989e2a241 upstream.
This was reverts commit 8009479ee919b9a91674f48050ccbff64eafedaa.
It was originally in x86/urgent, but was deemed wrong so got zapped.
But in the meantime, x86/urgent had been merged into x86/apic to
resolve a conflict. I didn't notice the merge so didn't zap it
from x86/apic and it managed to make it up with the x86/apic
material.
The reverted commit is known to cause some KASAN problems.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:03 +02:00
Pawan Gupta
367b4ce0d7
x86/bugs: Use fixed addressing for VERW operand
...
commit 8009479ee919b9a91674f48050ccbff64eafedaa upstream.
The macro used for MDS mitigation executes VERW with relative
addressing for the operand. This was necessary in earlier versions of
the series. Now it is unnecessary and creates a problem for backports
on older kernels that don't support relocations in alternatives.
Relocation support was added by commit 270a69c448 ("x86/alternative:
Support relocations in alternatives"). Also asm for fixed addressing
is much cleaner than relative RIP addressing.
Simplify the asm by using fixed addressing for VERW operand.
[ dhansen: tweak changelog ]
Closes: https://lore.kernel.org/lkml/20558f89-299b-472e-9a96-171403a83bd6@suse.com/
Fixes: baf8361e5455 ("x86/bugs: Add asm helpers for executing VERW")
Reported-by: Nikolay Borisov <nik.borisov@suse.com >
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com >
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com >
Link: https://lore.kernel.org/all/20240226-verw-arg-fix-v1-1-7b37ee6fd57d%40linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:02 +02:00
Quinn Tran
a492d6dad9
scsi: qla2xxx: Delay I/O Abort on PCI error
...
commit 591c1fdf2016d118b8fbde427b796fac13f3f070 upstream.
Currently when PCI error is detected, I/O is aborted manually through the
ABORT IOCB mechanism which is not guaranteed to succeed.
Instead, wait for the OS or system to notify driver to wind down I/O
through the pci_error_handlers api. Set eeh_busy flag to pause all traffic
and wait for I/O to drain.
Cc: stable@vger.kernel.org
Signed-off-by: Quinn Tran <qutran@marvell.com >
Signed-off-by: Nilesh Javali <njavali@marvell.com >
Link: https://lore.kernel.org/r/20240227164127.36465-11-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:02 +02:00
Saurav Kashyap
29520a334f
scsi: qla2xxx: Change debug message during driver unload
...
commit b5a30840727a3e41d12a336d19f6c0716b299161 upstream.
Upon driver unload, purge_mbox flag is set and the heartbeat monitor thread
detects this flag and does not send the mailbox command down to FW with a
debug message "Error detected: purge[1] eeh[0] cmd=0x0, Exiting". This
being not a real error, change the debug message.
Cc: stable@vger.kernel.org
Signed-off-by: Saurav Kashyap <skashyap@marvell.com >
Signed-off-by: Nilesh Javali <njavali@marvell.com >
Link: https://lore.kernel.org/r/20240227164127.36465-10-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:02 +02:00
Saurav Kashyap
f85af9f1aa
scsi: qla2xxx: Fix double free of fcport
...
commit 82f522ae0d97119a43da53e0f729275691b9c525 upstream.
The server was crashing after LOGO because fcport was getting freed twice.
-----------[ cut here ]-----------
kernel BUG at mm/slub.c:371!
invalid opcode: 0000 1 SMP PTI
CPU: 35 PID: 4610 Comm: bash Kdump: loaded Tainted: G OE --------- - - 4.18.0-425.3.1.el8.x86_64 #1
Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021
RIP: 0010:set_freepointer.part.57+0x0/0x10
RSP: 0018:ffffb07107027d90 EFLAGS: 00010246
RAX: ffff9cb7e3150000 RBX: ffff9cb7e332b9c0 RCX: ffff9cb7e3150400
RDX: 0000000000001f37 RSI: 0000000000000000 RDI: ffff9cb7c0005500
RBP: fffff693448c5400 R08: 0000000080000000 R09: 0000000000000009
R10: 0000000000000000 R11: 0000000000132af0 R12: ffff9cb7c0005500
R13: ffff9cb7e3150000 R14: ffffffffc06990e0 R15: ffff9cb7ea85ea58
FS: 00007ff6b79c2740(0000) GS:ffff9cb8f7ec0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055b426b7d700 CR3: 0000000169c18002 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
kfree+0x238/0x250
qla2x00_els_dcmd_sp_free+0x20/0x230 [qla2xxx]
? qla24xx_els_dcmd_iocb+0x607/0x690 [qla2xxx]
qla2x00_issue_logo+0x28c/0x2a0 [qla2xxx]
? qla2x00_issue_logo+0x28c/0x2a0 [qla2xxx]
? kernfs_fop_write+0x11e/0x1a0
Remove one of the free calls and add check for valid fcport. Also use
function qla2x00_free_fcport() instead of kfree().
Cc: stable@vger.kernel.org
Signed-off-by: Saurav Kashyap <skashyap@marvell.com >
Signed-off-by: Nilesh Javali <njavali@marvell.com >
Link: https://lore.kernel.org/r/20240227164127.36465-9-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:02 +02:00
Saurav Kashyap
f14cee7a88
scsi: qla2xxx: Fix double free of the ha->vp_map pointer
...
commit e288285d47784fdcf7c81be56df7d65c6f10c58b upstream.
Coverity scan reported potential risk of double free of the pointer
ha->vp_map. ha->vp_map was freed in qla2x00_mem_alloc(), and again freed
in function qla2x00_mem_free(ha).
Assign NULL to vp_map and kfree take care of NULL.
Cc: stable@vger.kernel.org
Signed-off-by: Saurav Kashyap <skashyap@marvell.com >
Signed-off-by: Nilesh Javali <njavali@marvell.com >
Link: https://lore.kernel.org/r/20240227164127.36465-8-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:02 +02:00
Quinn Tran
8de1584ec4
scsi: qla2xxx: Fix command flush on cable pull
...
commit a27d4d0e7de305def8a5098a614053be208d1aa1 upstream.
System crash due to command failed to flush back to SCSI layer.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
PGD 0 P4D 0
Oops: 0000 [#1 ] SMP NOPTI
CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G OE --------- - - 4.18.0-372.9.1.el8.x86_64 #1
Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021
Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]
RIP: 0010:__wake_up_common+0x4c/0x190
Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75
RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086
RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320
RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8
R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20
R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
__wake_up_common_lock+0x7c/0xc0
qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]
qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0
? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]
qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200.
? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]
qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1
? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]
qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0
? __switch_to+0x10c/0x450
? process_one_work+0x1a7/0x360
qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201.
? worker_thread+0x1ce/0x390
? create_worker+0x1a0/0x1a0
qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70
? kthread+0x10a/0x120
qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8
? set_kthread_struct+0x40/0x40
qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed.
? ret_from_fork+0x1f/0x40
qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout
The system was under memory stress where driver was not able to allocate an
SRB to carry out error recovery of cable pull. The failure to flush causes
upper layer to start modifying scsi_cmnd. When the system frees up some
memory, the subsequent cable pull trigger another command flush. At this
point the driver access a null pointer when attempting to DMA unmap the
SGL.
Add a check to make sure commands are flush back on session tear down to
prevent the null pointer access.
Cc: stable@vger.kernel.org
Signed-off-by: Quinn Tran <qutran@marvell.com >
Signed-off-by: Nilesh Javali <njavali@marvell.com >
Link: https://lore.kernel.org/r/20240227164127.36465-7-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:02 +02:00
Quinn Tran
adc9702642
scsi: qla2xxx: NVME|FCP prefer flag not being honored
...
commit 69aecdd410106dc3a8f543a4f7ec6379b995b8d0 upstream.
Changing of [FCP|NVME] prefer flag in flash has no effect on driver. For
device that supports both FCP + NVMe over the same connection, driver
continues to connect to this device using the previous successful login
mode.
On completion of flash update, adapter will be reset. Driver will
reset the prefer flag based on setting from flash.
Cc: stable@vger.kernel.org
Signed-off-by: Quinn Tran <qutran@marvell.com >
Signed-off-by: Nilesh Javali <njavali@marvell.com >
Link: https://lore.kernel.org/r/20240227164127.36465-6-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:02 +02:00
Bikash Hazarika
b31a120b81
scsi: qla2xxx: Update manufacturer detail
...
commit 688fa069fda6fce24d243cddfe0c7024428acb74 upstream.
Update manufacturer detail from "Marvell Semiconductor, Inc." to
"Marvell".
Cc: stable@vger.kernel.org
Signed-off-by: Bikash Hazarika <bhazarika@marvell.com >
Signed-off-by: Nilesh Javali <njavali@marvell.com >
Link: https://lore.kernel.org/r/20240227164127.36465-5-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:02 +02:00
Quinn Tran
be895682c5
scsi: qla2xxx: Split FCE|EFT trace control
...
commit 76a192e1a566e15365704b9f8fb3b70825f85064 upstream.
Current code combines the allocation of FCE|EFT trace buffers and enables
the features all in 1 step.
Split this step into separate steps in preparation for follow-on patch to
allow user to have a choice to enable / disable FCE trace feature.
Cc: stable@vger.kernel.org
Reported-by: kernel test robot <lkp@intel.com >
Signed-off-by: Quinn Tran <qutran@marvell.com >
Signed-off-by: Nilesh Javali <njavali@marvell.com >
Link: https://lore.kernel.org/r/20240227164127.36465-4-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:01 +02:00
Quinn Tran
8ec0d55020
scsi: qla2xxx: Fix N2N stuck connection
...
commit 881eb861ca3877300570db10abbf11494e48548d upstream.
Disk failed to rediscover after chip reset error injection. The chip reset
happens at the time when a PLOGI is being sent. This causes a flag to be
left on which blocks the retry. Clear the blocking flag.
Cc: stable@vger.kernel.org
Signed-off-by: Quinn Tran <qutran@marvell.com >
Signed-off-by: Nilesh Javali <njavali@marvell.com >
Link: https://lore.kernel.org/r/20240227164127.36465-3-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:01 +02:00
Quinn Tran
ef23850940
scsi: qla2xxx: Prevent command send on chip reset
...
commit 4895009c4bb72f71f2e682f1e7d2c2d96e482087 upstream.
Currently IOCBs are allowed to push through while chip reset could be in
progress. During chip reset the outstanding_cmds array is cleared
twice. Once when any command on this array is returned as failed and
secondly when the array is initialize to zero. If a command is inserted on
to the array between these intervals, then the command will be lost. Check
for chip reset before sending IOCB.
Cc: stable@vger.kernel.org
Signed-off-by: Quinn Tran <qutran@marvell.com >
Signed-off-by: Nilesh Javali <njavali@marvell.com >
Link: https://lore.kernel.org/r/20240227164127.36465-2-njavali@marvell.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com >
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com >
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:01 +02:00
Christian A. Ehrhardt
db4aaf281a
usb: typec: ucsi: Clear UCSI_CCI_RESET_COMPLETE before reset
...
commit 3de4f996a0b5412aa451729008130a488f71563e upstream.
Check the UCSI_CCI_RESET_COMPLETE complete flag before starting
another reset. Use a UCSI_SET_NOTIFICATION_ENABLE command to clear
the flag if it is set.
Signed-off-by: Christian A. Ehrhardt <lk@c--e.de >
Cc: stable <stable@kernel.org >
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com >
Tested-by: Neil Armstrong <neil.armstrong@linaro.org > # on SM8550-QRD
Link: https://lore.kernel.org/r/20240320073927.1641788-6-lk@c--e.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:01 +02:00
Christian A. Ehrhardt
1f510af8db
usb: typec: ucsi_acpi: Refactor and fix DELL quirk
...
commit 6aaceb7d9cd00f3e065dc4b054ecfe52c5253b03 upstream.
Some DELL systems don't like UCSI_ACK_CC_CI commands with the
UCSI_ACK_CONNECTOR_CHANGE but not the UCSI_ACK_COMMAND_COMPLETE
bit set. The current quirk still leaves room for races because
it requires two consecutive ACK commands to be sent.
Refactor and significantly simplify the quirk to fix this:
Send a dummy command and bundle the connector change ack with the
command completion ack in a single UCSI_ACK_CC_CI command.
This removes the need to probe for the quirk.
While there define flag bits for struct ucsi_acpi->flags in ucsi_acpi.c
and don't re-use definitions from ucsi.h for struct ucsi->flags.
Fixes: f3be347ea42d ("usb: ucsi_acpi: Quirk to ack a connector change ack cmd")
Cc: stable@vger.kernel.org
Signed-off-by: Christian A. Ehrhardt <lk@c--e.de >
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com >
Tested-by: Neil Armstrong <neil.armstrong@linaro.org > # on SM8550-QRD
Link: https://lore.kernel.org/r/20240320073927.1641788-5-lk@c--e.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org >
2024-04-03 15:29:01 +02:00