The drm fbdev emulation does not forward mode changes to the driver,
and hence all changes where rejected in 865afb11949e ("drm/fb-helper:
reject any changes to the fbdev").
Unfortunately this resulted in bugs on multiple monitor systems with
different resolutions. In that case the fbdev emulation code sizes the
underlying framebuffer for the largest screen (which dictates
x/yres_virtual), but adjust the fbdev x/yres to match the smallest
resolution. The above mentioned patch failed to realize that, and
errornously validated x/yres against the fb dimensions.
This was fixed by just dropping the validation for too small sizes,
which restored vt switching with 12ffed96d436 ("drm/fb-helper: Allow
var->x/yres(_virtual) < fb->width/height again").
But this also restored all kinds of validation issues and their
fallout in the notoriously buggy fbcon code for too small sizes. Since
no one is volunteering to really make fbcon and vc/vt fully robust
against these math issues make sure this barn door is closed for good
again.
Since it's a bit tricky to remember the x/yres we picked across both
the newer generic fbdev emulation and the older code with more driver
involvement, we simply check that it doesn't change. This relies on
drm_fb_helper_fill_var() having done things correctly, and nothing
having trampled it yet.
Note that this leaves all the other fbdev drivers out in the rain.
Given that distros have finally started to move away from those
completely for real I think that's good enough. The code it spaghetti
enough that I do not feel confident to even review fixes for it.
What might help fbdev is doing something similar to what was done in
a49145acfb97 ("fbmem: add margin check to fb_check_caps()") and ensure
x/yres_virtual aren't too small, for some value of "too small". Maybe
checking that they're at least x/yres makes sense?
Fixes: 12ffed96d436 ("drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again")
Cc: Michel Dänzer <michel.daenzer(a)amd.com>
Cc: Daniel Stone <daniels(a)collabora.com>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Cc: Maxime Ripard <mripard(a)kernel.org>
Cc: Thomas Zimmermann <tzimmermann(a)suse.de>
Cc: <stable(a)vger.kernel.org> # v4.11+
Cc: Helge Deller <deller(a)gmx.de>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: openeuler-security(a)openeuler.org
Cc: guodaxing(a)huawei.com
Cc: Weigang (Jimmy) <weigang12(a)huawei.com>
Reported-by: Weigang (Jimmy) <weigang12(a)huawei.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com>
---
Note: Weigang asked for this to stay under embargo until it's all
review and tested.
-Daniel
---
drivers/gpu/drm/drm_fb_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 695997ae2a7c..5664a177a404 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1355,8 +1355,8 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
* to KMS, hence fail if different settings are requested.
*/
if (var->bits_per_pixel > fb->format->cpp[0] * 8 ||
- var->xres > fb->width || var->yres > fb->height ||
- var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
+ var->xres != info->var.xres || var->yres != info->var.yres ||
+ var->xres_virtual != fb->width || var->yres_virtual != fb->height) {
drm_dbg_kms(dev, "fb requested width/height/bpp can't fit in current fb "
"request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
var->xres, var->yres, var->bits_per_pixel,
--
2.36.0
In a scenario where livepatch and aggrprobe coexist on the same function
entry, and if this aggrprobe has a post_handler, arm_kprobe() always
fails as both livepatch and aggrprobe with post_handler will use
FTRACE_OPS_FL_IPMODIFY.
Since register_aggr_kprobe() doesn't roll back the post_handler on
failed arm_kprobe(), this aggrprobe will no longer be available even if
all kprobes on this aggrprobe don't have the post_handler.
Fix to roll back the aggrprobe post_handler for this case.
With this patch, if a kprobe that has the post_handler is removed from
this aggrprobe (since arm_kprobe() failed), it will be available again.
Fixes: 12310e343755 ("kprobes: Propagate error from arm_kprobe_ftrace()")
Signed-off-by: Chuang W <nashuiliang(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
---
v1 -> v2:
- Add commit details
kernel/kprobes.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index f214f8c088ed..0610b02a3a05 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1300,6 +1300,7 @@ static int register_aggr_kprobe(struct kprobe *orig_p, struct kprobe *p)
{
int ret = 0;
struct kprobe *ap = orig_p;
+ kprobe_post_handler_t old_post_handler = NULL;
cpus_read_lock();
@@ -1351,6 +1352,9 @@ static int register_aggr_kprobe(struct kprobe *orig_p, struct kprobe *p)
/* Copy the insn slot of 'p' to 'ap'. */
copy_kprobe(ap, p);
+
+ /* save the old post_handler */
+ old_post_handler = ap->post_handler;
ret = add_new_kprobe(ap, p);
out:
@@ -1365,6 +1369,7 @@ static int register_aggr_kprobe(struct kprobe *orig_p, struct kprobe *p)
ret = arm_kprobe(ap);
if (ret) {
ap->flags |= KPROBE_FLAG_DISABLED;
+ ap->post_handler = old_post_handler;
list_del_rcu(&p->list);
synchronize_rcu();
}
--
2.34.1
[Why&How]
When the a 3d array is used by indexing with only one dimension in an if
condition, the addresses get compared instead of the intended value stored in the
array. GCC 12.1 caught this error:
drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/dml/dcn32/display_mode_vba_32.c: In function ‘DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation’:
drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/dml/dcn32/display_mode_vba_32.c:1007:45: error: the comparison will always evaluate as ‘true’ for the address of ‘use_one_row_for_frame_flip’ will never be NULL [-Werror=address]
1007 | if (v->use_one_row_for_frame_flip[k]) {
| ^
In file included from ./drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/dml/display_mode_lib.h:32,
from ./drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/dc.h:45,
from drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/dml/dcn32/display_mode_vba_32.c:30:
./drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/dml/display_mode_vba.h:605:14: note: ‘use_one_row_for_frame_flip’ declared here
605 | bool use_one_row_for_frame_flip[DC__VOLTAGE_STATES][2][DC__NUM_DPP__MAX];
|
Fix this by explicitly specifying the last two indices.
Fixes: d03037269bf2 ("drm/amd/display: DML changes for DCN32/321")
Cc: Stable(a)vger.kernel.org
Signed-off-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com>
---
drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
index b9f5bfa67791..c920d71fbd56 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c
@@ -994,7 +994,7 @@ static void DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
+ mode_lib->vba.DPPPerPlane[k]
* (v->PDEAndMetaPTEBytesFrame[k]
+ v->MetaRowByte[k]);
- if (v->use_one_row_for_frame_flip[k]) {
+ if (v->use_one_row_for_frame_flip[k][0][0]) {
mode_lib->vba.TotImmediateFlipBytes =
mode_lib->vba.TotImmediateFlipBytes
+ 2 * v->PixelPTEBytesPerRow[k];
--
2.36.1