[PATCH 0/1] drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

[PATCH 0/1] drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

[Leandro Ribeiro]

This replaces a WARN() with drm_warn() in
validate_blend_mode_for_alpha_formats().

The condition is expected to be triggered by existing drivers while they
adapt to the new blend mode requirement, so it should not use the kernel
warning report mechanism. WARN() output can cause fuzzers to stop when
they encounter a "WARNING:" message.

drm_warn() keeps the warning visible to driver developers without
triggering a WARN().

Leandro Ribeiro (1):
  drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

 drivers/gpu/drm/drm_mode_config.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-- 
2.55.0

[PATCH 1/1] drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

[Leandro Ribeiro]

Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
with alpha exposed") introduced a WARN() to let driver developers know
that a previously valid behavior should now be changed.

But WARN() should not be used for that, as it's a kernel warning report
mechanism for conditions that are not expected to happen. It also
produces a stack trace. Instead, a simple warning-level log message
should have been used, as drivers were expected to trigger the
condition.

This is causing problems for fuzzers, as they may stop when encountering
a "BUG:" or "WARNING:" in the logs.

Replace WARN() with drm_warn() in this function, avoiding these issues.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
---
 drivers/gpu/drm/drm_mode_config.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index 3bcc7bf0900c..3d9c554e08a8 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -869,8 +869,9 @@ static void validate_blend_mode_for_alpha_formats(struct drm_plane *plane)
 	for (i = 0; i < plane->format_count; i++) {
 		fmt = drm_format_info(plane->format_types[i]);
 		if (fmt->has_alpha) {
-			WARN(1, "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup",
-			     plane->base.id, plane->name);
+			drm_warn(plane->dev,
+				 "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup",
+				 plane->base.id, plane->name);
 			break;
 		}
 	}
-- 
2.55.0

Re: [PATCH 1/1] drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unconditional dereference of `drm_format_info()` return value leads to NULL pointer dereference for unrecognized formats.
--

--- Patch [1]: [PATCH 1/1] drm: use drm_warn() in validate_blend_mode_for_alpha_formats() ---
commit 8bcc8b572cfd0496af9f1e8dd202524f50670fa0
Author: Leandro Ribeiro <leandro.ribeiro@collabora.com>

drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

This commit replaces WARN() with drm_warn() in
validate_blend_mode_for_alpha_formats() to prevent fuzzers from tripping
over kernel warning reports for expected driver validation issues.

> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index 3bcc7bf0900c4..3d9c554e08a87 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -869,8 +869,9 @@ static void validate_blend_mode_for_alpha_formats(struct drm_plane *plane)
>  	for (i = 0; i < plane->format_count; i++) {
>  		fmt = drm_format_info(plane->format_types[i]);
>  		if (fmt->has_alpha) {

[Severity: High]
This is a pre-existing issue, but could this unconditionally dereference
fmt if drm_format_info() returns NULL?

If a driver exposes an unrecognized or custom pixel format that the core
DRM does not know about, drm_format_info() returns NULL. Since the
purpose of this validation function is to catch driver bugs, should we
check if fmt is NULL before checking fmt->has_alpha to avoid a kernel
panic?

> -			WARN(1, "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup",
> -			     plane->base.id, plane->name);
> +			drm_warn(plane->dev,
> +				 "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup",
> +				 plane->base.id, plane->name);
>  			break;
>  		}
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729214505.185776-2-leandro.ribeiro@collabora.com?part=1

Re: [PATCH 1/1] drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

[Tetsuo Handa]

On 2026/07/30 6:45, Leandro Ribeiro wrote:
> Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
> with alpha exposed") introduced a WARN() to let driver developers know
> that a previously valid behavior should now be changed.
> 
> But WARN() should not be used for that, as it's a kernel warning report
> mechanism for conditions that are not expected to happen. It also
> produces a stack trace. Instead, a simple warning-level log message
> should have been used, as drivers were expected to trigger the
> condition.
> 
> This is causing problems for fuzzers, as they may stop when encountering
> a "BUG:" or "WARNING:" in the logs.
> 
> Replace WARN() with drm_warn() in this function, avoiding these issues.

Thank you. But could something like

  pr_warn("[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup. Please fix.", plane->base.id, plane->name);
  dump_stack();

be less prone to get oversighted (because of printing about 10+ lines)?

Re: [PATCH 1/1] drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

[Leandro Ribeiro]

On 7/29/26 7:13 PM, Tetsuo Handa wrote:
> On 2026/07/30 6:45, Leandro Ribeiro wrote:
>> Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
>> with alpha exposed") introduced a WARN() to let driver developers know
>> that a previously valid behavior should now be changed.
>>
>> But WARN() should not be used for that, as it's a kernel warning report
>> mechanism for conditions that are not expected to happen. It also
>> produces a stack trace. Instead, a simple warning-level log message
>> should have been used, as drivers were expected to trigger the
>> condition.
>>
>> This is causing problems for fuzzers, as they may stop when encountering
>> a "BUG:" or "WARNING:" in the logs.
>>
>> Replace WARN() with drm_warn() in this function, avoiding these issues.
> 
> Thank you. But could something like
> 
>   pr_warn("[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup. Please fix.", plane->base.id, plane->name);
>   dump_stack();
> 
> be less prone to get oversighted (because of printing about 10+ lines)?
> 

I see the point about making the message harder to overlook, but
honestly I feel like the stack trace would be overkill here.

The error message is more important than the stack trace itself in this
case, and I think the warning should be enough to draw attention to the
issue.

-- 
Leandro Ribeiro

Re: [PATCH 1/1] drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

[Tetsuo Handa]

On 2026/07/31 3:54, Leandro Ribeiro wrote:
> I see the point about making the message harder to overlook, but
> honestly I feel like the stack trace would be overkill here.
> 
> The error message is more important than the stack trace itself in this
> case, and I think the warning should be enough to draw attention to the
> issue.

OK. Then, please consider

 			drm_warn(plane->dev,
-				 "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup",
+				 "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup. Please fix.,
 				 plane->base.id, plane->name);

to indicate that developers have something to do.

Re: [PATCH 1/1] drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

[Leandro Ribeiro]

On 7/30/26 8:14 PM, Tetsuo Handa wrote:
> On 2026/07/31 3:54, Leandro Ribeiro wrote:
>> I see the point about making the message harder to overlook, but
>> honestly I feel like the stack trace would be overkill here.
>>
>> The error message is more important than the stack trace itself in this
>> case, and I think the warning should be enough to draw attention to the
>> issue.
> 
> OK. Then, please consider
> 
>  			drm_warn(plane->dev,
> -				 "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup",
> +				 "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup. Please fix.,
>  				 plane->base.id, plane->name);
> 
> to indicate that developers have something to do.
> 

Sure, sounds good! I'll change this, thank you.

-- 
Leandro Ribeiro

Re: [PATCH 1/1] drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

[Jani Nikula]

On Wed, 29 Jul 2026, Leandro Ribeiro <leandro.ribeiro@collabora.com> wrote:
> Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
> with alpha exposed") introduced a WARN() to let driver developers know
> that a previously valid behavior should now be changed.

I should've chimed in way back when, but in retrospect it's a bit
presumptuous to add a commit that puts the burden of the change on the
driver developers, without so much as identifying which drivers or
getting an ack from them.

This is really not unlike the __deprecated attribute, see commit
771c035372a0 ("deprecate the '__deprecated' attribute warnings entirely
and for good"), but this one's runtime not build.

> But WARN() should not be used for that, as it's a kernel warning report
> mechanism for conditions that are not expected to happen. It also
> produces a stack trace. Instead, a simple warning-level log message
> should have been used, as drivers were expected to trigger the
> condition.
>
> This is causing problems for fuzzers, as they may stop when encountering
> a "BUG:" or "WARNING:" in the logs.
>
> Replace WARN() with drm_warn() in this function, avoiding these issues.

Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")

> Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
> ---
>  drivers/gpu/drm/drm_mode_config.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index 3bcc7bf0900c..3d9c554e08a8 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -869,8 +869,9 @@ static void validate_blend_mode_for_alpha_formats(struct drm_plane *plane)
>  	for (i = 0; i < plane->format_count; i++) {
>  		fmt = drm_format_info(plane->format_types[i]);
>  		if (fmt->has_alpha) {
> -			WARN(1, "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup",
> -			     plane->base.id, plane->name);
> +			drm_warn(plane->dev,
> +				 "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup",
> +				 plane->base.id, plane->name);
>  			break;
>  		}
>  	}

-- 
Jani Nikula, Intel

Re: [PATCH 1/1] drm: use drm_warn() in validate_blend_mode_for_alpha_formats()

[Leandro Ribeiro]

On 7/30/26 6:14 AM, Jani Nikula wrote:
> On Wed, 29 Jul 2026, Leandro Ribeiro <leandro.ribeiro@collabora.com> wrote:
>> Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
>> with alpha exposed") introduced a WARN() to let driver developers know
>> that a previously valid behavior should now be changed.
> 
> I should've chimed in way back when, but in retrospect it's a bit
> presumptuous to add a commit that puts the burden of the change on the
> driver developers, without so much as identifying which drivers or
> getting an ack from them.
> 
> This is really not unlike the __deprecated attribute, see commit
> 771c035372a0 ("deprecate the '__deprecated' attribute warnings entirely
> and for good"), but this one's runtime not build.
> 

I agree. I hadn't considered the driver coordination aspect when
proposing that change.

>> But WARN() should not be used for that, as it's a kernel warning report
>> mechanism for conditions that are not expected to happen. It also
>> produces a stack trace. Instead, a simple warning-level log message
>> should have been used, as drivers were expected to trigger the
>> condition.
>>
>> This is causing problems for fuzzers, as they may stop when encountering
>> a "BUG:" or "WARNING:" in the logs.
>>
>> Replace WARN() with drm_warn() in this function, avoiding these issues.
> 
> Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
> 
>> Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
>> ---
>>  drivers/gpu/drm/drm_mode_config.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
>> index 3bcc7bf0900c..3d9c554e08a8 100644
>> --- a/drivers/gpu/drm/drm_mode_config.c
>> +++ b/drivers/gpu/drm/drm_mode_config.c
>> @@ -869,8 +869,9 @@ static void validate_blend_mode_for_alpha_formats(struct drm_plane *plane)
>>  	for (i = 0; i < plane->format_count; i++) {
>>  		fmt = drm_format_info(plane->format_types[i]);
>>  		if (fmt->has_alpha) {
>> -			WARN(1, "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup",
>> -			     plane->base.id, plane->name);
>> +			drm_warn(plane->dev,
>> +				 "[PLANE:%d:%s] pixel format with alpha exposed but blend mode not setup",
>> +				 plane->base.id, plane->name);
>>  			break;
>>  		}
>>  	}
> 

-- 
Leandro Ribeiro