The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
0d7c1153d929 ("io_uring: Clean up a false-positive warning from GCC 9.3.0")
d1fd1c201d75 ("io_uring: simplify selected buf handling")
3648e5265cfa ("io_uring: move up io_put_kbuf() and io_put_rw_kbuf()")
04c76b41ca97 ("io_uring: add option to skip CQE posting")
913a571affed ("io_uring: clean cqe filling functions")
7297ce3d5944 ("io_uring: improve send/recv error handling")
54daa9b2d80a ("io_uring: correct fill events helpers types")
867f8fa5aeb7 ("io_uring: inline io_req_needs_clean()")
d17e56eb4907 ("io_uring: remove struct io_completion")
d886e185a128 ("io_uring: control ->async_data with a REQ_F flag")
fff4e40e3094 ("io_uring: delay req queueing into compl-batch list")
51d48dab62ed ("io_uring: add more likely/unlikely() annotations")
7e3709d57651 ("io_uring: optimise kiocb layout")
30d51dd4ad20 ("io_uring: clean up buffer select")
a1cdbb4cb5f7 ("io_uring: comment why inline complete calls io_clean_op()")
ef05d9ebcc92 ("io_uring: kill off ->inflight_entry field")
6962980947e2 ("io_uring: restructure submit sqes to_submit checks")
d9f9d2842c91 ("io_uring: reshuffle queue_sqe completion handling")
f5ed3bcd5b11 ("io_uring: optimise batch completion")
b3fa03fd1b17 ("io_uring: convert iopoll_completed to store_release")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 0d7c1153d9291197c1dc473cfaade77acb874b4b Mon Sep 17 00:00:00 2001
From: Alviro Iskandar Setiawan <alviro.iskandar(a)gmail.com>
Date: Mon, 7 Feb 2022 21:05:33 +0700
Subject: [PATCH] io_uring: Clean up a false-positive warning from GCC 9.3.0
In io_recv(), if import_single_range() fails, the @flags variable is
uninitialized, then it will goto out_free.
After the goto, the compiler doesn't know that (ret < min_ret) is
always true, so it thinks the "if ((flags & MSG_WAITALL) ..." path
could be taken.
The complaint comes from gcc-9 (Debian 9.3.0-22) 9.3.0:
```
fs/io_uring.c:5238 io_recvfrom() error: uninitialized symbol 'flags'
```
Fix this by bypassing the @ret and @flags check when
import_single_range() fails.
Reasons:
1. import_single_range() only returns -EFAULT when it fails.
2. At that point, @flags is uninitialized and shouldn't be read.
Reported-by: kernel test robot <lkp(a)intel.com>
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Reported-by: "Chen, Rong A" <rong.a.chen(a)intel.com>
Link: https://lore.gnuweeb.org/timl/d33bb5a9-8173-f65b-f653-51fc0681c6d6@intel.co…
Cc: Pavel Begunkov <asml.silence(a)gmail.com>
Suggested-by: Ammar Faizi <ammarfaizi2(a)gnuweeb.org>
Fixes: 7297ce3d59449de49d3c9e1f64ae25488750a1fc ("io_uring: improve send/recv error handling")
Signed-off-by: Alviro Iskandar Setiawan <alviro.iskandar(a)gmail.com>
Signed-off-by: Ammar Faizi <ammarfaizi2(a)gnuweeb.org>
Link: https://lore.kernel.org/r/20220207140533.565411-1-ammarfaizi2@gnuweeb.org
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 2e04f718319d..3445c4da0153 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -5228,7 +5228,6 @@ static int io_recv(struct io_kiocb *req, unsigned int issue_flags)
min_ret = iov_iter_count(&msg.msg_iter);
ret = sock_recvmsg(sock, &msg, flags);
-out_free:
if (ret < min_ret) {
if (ret == -EAGAIN && force_nonblock)
return -EAGAIN;
@@ -5236,9 +5235,9 @@ static int io_recv(struct io_kiocb *req, unsigned int issue_flags)
ret = -EINTR;
req_set_fail(req);
} else if ((flags & MSG_WAITALL) && (msg.msg_flags & (MSG_TRUNC | MSG_CTRUNC))) {
+out_free:
req_set_fail(req);
}
-
__io_req_complete(req, issue_flags, ret, io_put_kbuf(req));
return 0;
}
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Possible dependencies:
0ddadc3a2208 ("drm/amdgpu: correct MEC number for gfx11 APUs")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 0ddadc3a2208aedb1b27dbb76d0b4e722b5b527a Mon Sep 17 00:00:00 2001
From: Lang Yu <Lang.Yu(a)amd.com>
Date: Wed, 11 Jan 2023 09:52:11 +0800
Subject: [PATCH] drm/amdgpu: correct MEC number for gfx11 APUs
There is only one MEC on these APUs.
Signed-off-by: Lang Yu <Lang.Yu(a)amd.com>
Reviewed-by: Aaron Liu <aaron.liu(a)amd.com>
Reviewed-by: Yifan Zhang <yifan1.zhang(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org # 6.1.x
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index a56c6e106d00..b9b57a66e113 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -1287,10 +1287,8 @@ static int gfx_v11_0_sw_init(void *handle)
switch (adev->ip_versions[GC_HWIP][0]) {
case IP_VERSION(11, 0, 0):
- case IP_VERSION(11, 0, 1):
case IP_VERSION(11, 0, 2):
case IP_VERSION(11, 0, 3):
- case IP_VERSION(11, 0, 4):
adev->gfx.me.num_me = 1;
adev->gfx.me.num_pipe_per_me = 1;
adev->gfx.me.num_queue_per_pipe = 1;
@@ -1298,6 +1296,15 @@ static int gfx_v11_0_sw_init(void *handle)
adev->gfx.mec.num_pipe_per_mec = 4;
adev->gfx.mec.num_queue_per_pipe = 4;
break;
+ case IP_VERSION(11, 0, 1):
+ case IP_VERSION(11, 0, 4):
+ adev->gfx.me.num_me = 1;
+ adev->gfx.me.num_pipe_per_me = 1;
+ adev->gfx.me.num_queue_per_pipe = 1;
+ adev->gfx.mec.num_mec = 1;
+ adev->gfx.mec.num_pipe_per_mec = 4;
+ adev->gfx.mec.num_queue_per_pipe = 4;
+ break;
default:
adev->gfx.me.num_me = 1;
adev->gfx.me.num_pipe_per_me = 1;
[Public]
Hi,
AMDGPU changed the codebase to use IP block versions rather than device IDs.
Some products that contain IP blocks "GC 11.0.4", "PSP 13.0.11" and "NBIO 7.7.1" work with the code in 6.1.y, but the various switch/case statements for IP version match are missing for these.
So the following minor changes allow those products to work with acceleration on 6.1.y:
69dc98bbd441 ("drm/amdgpu/discovery: enable soc21 common for GC 11.0.4")
d5fd8c89ed20 ("drm/amdgpu/discovery: enable gmc v11 for GC 11.0.4")
b952d6b3d3ff ("drm/amdgpu/discovery: enable gfx v11 for GC 11.0.4")
6a6af77570ad ("drm/amdgpu/discovery: enable mes support for GC v11.0.4")
94ab70685844 ("drm/amdgpu: set GC 11.0.4 family")
dd2d9c7fd771 ("drm/amdgpu/discovery: set the APU flag for GC 11.0.4")
1763cb65e870 ("drm/amdgpu: add gfx support for GC 11.0.4")
311d52367d0a ("drm/amdgpu: add soc21 common ip block support for GC 11.0.4")
d0ca8248999e ("drm/amdgpu: add gmc v11 support for GC 11.0.4")
7c1389f1b122 ("drm/amdgpu/discovery: add PSP IP v13.0.11 support")
16412a94364d ("drm/amdgpu/pm: enable swsmu for SMU IP v13.0.11")
51e7a2168769 ("drm/amdgpu: add smu 13 support for smu 13.0.11")
9f83e61201bb ("drm/amdgpu/pm: add GFXOFF control IP version check for SMU IP v13.0.11")
18ad18853cf2 ("drm/amdgpu/soc21: add mode2 asic reset for SMU IP v13.0.11")
069a5af97ce3 ("drm/amdgpu/pm: use the specific mailbox registers only for SMU IP v13.0.4")
7308ceb44663 ("drm/amdgpu/discovery: enable nbio support for NBIO v7.7.1")
2a0fe2ca6e9c ("drm/amdgpu: Enable pg/cg flags on GC11_0_4 for VCN")
2c83e3fd928b ("drm/amdgpu: enable PSP IP v13.0.11 support")
f2b91e5a7cc0 ("drm/amdgpu: enable GFX IP v11.0.4 CG support")
a89e2965da6e ("drm/amdgpu: enable GFX Power Gating for GC IP v11.0.4")
f9caa237372b ("drm/amdgpu: enable GFX Clock Gating control for GC IP v11.0.4")
97074216917b ("drm/amdgpu: add tmz support for GC 11.0.1")
2aecbe492a3c ("drm/amdgpu: add tmz support for GC IP v11.0.4")
Can these please be brought into 6.1.y? As amdgpu switched from device IDs to IP blocks these are akin to "device ID" support.
Thanks,
Hi Greg and Sasha,
Clang 16 (current main, next major release) errors when offsetof() has a
type defintion in it, in response to language in newer C standards
stating it is undefined behavior.
https://github.com/llvm/llvm-project/commit/e327b52766ed497e4779f4e652b9ad2…https://reviews.llvm.org/D133574
While this might be eventually demoted to just a warning, the kernel has
already cleaned up places that had this construct, so we can apply them
to the stable trees and avoid the issue altogether.
Please find attached mbox files for all supported stable trees, which
fix up the relevant instances for each tree using the upstream commits:
55228db2697c ("x86/fpu: Use _Alignof to avoid undefined behavior in TYPE_ALIGN")
09794a5a6c34 ("tracing: Use alignof__(struct {type b;}) instead of offsetof()")
The fpu commit uses _Alignof, which as far as I can tell was only
supported in GCC 4.7.0+. This is not a problem for mainline due to
requiring GCC 5.1.0+ but it could be relevant for old trees like 4.14,
which have an older minimum supported version. I hope people are not
using ancient compilers like that but I suppose if they are using 4.14,
they might just be stuck with old software...
If there are any issues or comments, please let me know.
Nathan
Hi,
I'd like to ask that the oops_limit series get included in -stable
releases. It's a recommended defense developed while writing this
report:
https://googleprojectzero.blogspot.com/2023/01/exploiting-null-dereferences…
I've had a few people ask about having it in -stable, for example:
https://lore.kernel.org/lkml/20230119201023.4003-1-sj@kernel.org
This is the series:
9360d035a579 panic: Separate sysctl logic from CONFIG_SMP
d4ccd54d28d3 exit: Put an upper limit on how often we can oops
9db89b411170 exit: Expose "oops_count" to sysfs
de92f65719cd exit: Allow oops_limit to be disabled
79cc1ba7badf panic: Consolidate open-coded panic_on_warn checks
9fc9e278a5c0 panic: Introduce warn_limit
8b05aa263361 panic: Expose "warn_count" to sysfs
00dd027f721e docs: Fix path paste-o for /sys/kernel/warn_count
7535b832c639 exit: Use READ_ONCE() for all oops/warn limit reads
For v6.1.x they apply cleanly and behave as expected.
I'm hoping someone can step up and do backports for v5.15.x and earlier,
as there appear to be a number of conflicts and I'm swamped with other
stuff to do. :P
Thanks!
-Kees
--
Kees Cook