linux-kernel - Re: [PATCH v3 0/3] drm/draw: add check API to avoid spurious WARN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1ff8c562-2d1a-4e77-85d6-62d9f85a4a31@redhat.com>
Date: Fri, 19 Dec 2025 23:11:10 +0100
From: Jocelyn Falempe <jfalempe@...hat.com>
To: Francesco Valla <francesco@...la.it>,
 Javier Martinez Canillas <javierm@...hat.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/3] drm/draw: add check API to avoid spurious WARN

On 17/12/2025 09:06, Francesco Valla wrote:
> When using the DRM draw support, the only way to check if a color can be
> converted from XRGB8888 to a target format is currently to attempt an
> actual conversion using drm_draw_color_from_xrgb8888(). This function
> however will print a WARN the first time a conversion cannot be
> performed, leading to two potential issues:
> 
>   - a WARN is emitted without a real reason if the caller is only
>     attempting a conversion to check if a format can be supported (which
>     is the case for two of the current user of this API);
>   - a failing call following the first one is not emitting a WARN, but a
>     "valid" color value (0x00000000) is returned nevertheless.
> 
> The first issue was observed while using drm_log on a Beagleplay, which
> lists AR12 as the first format for its HDMI modesets.
> 
> The target of this patch set is to improve this situation; the first
> patch introduces a new API devoted only to check if a conversion from
> XRGB8888 to the specified format can be performed, while the other two
> substitute drm_draw_color_from_xrgb8888() with this new API in the
> current users (drm_panic and drm_log) where relevant.

I just pushed it to drm-misc/drm-misc-next

Thanks for your contribution.

-- 

Jocelyn

> 
> Signed-off-by: Francesco Valla <francesco@...la.it>
> ---
> Changes in v3:
> - Collected R-b tags from Jocelyn (thank you!)
> - Link to v2: https://lore.kernel.org/r/20251014-drm_draw_conv_check-v2-0-05bef3eb06fb@valla.it
> 
> Changes in v2:
> - Moved to dedicated switch cases in separate functions instead of
>    single one inside common function.
> - Fix copy-paste error in commit message.
> 
> Link to v1: https://lore.kernel.org/r/20251005-drm_draw_conv_check-v1-0-9c814d9362f6@valla.it
> 
> ---
> Francesco Valla (3):
>        drm/draw: add drm_draw_can_convert_from_xrgb8888
>        drm/log: avoid WARN when searching for usable format
>        drm/panic: avoid WARN when checking format support
> 
>   drivers/gpu/drm/clients/drm_log.c   |  2 +-
>   drivers/gpu/drm/drm_draw.c          | 29 +++++++++++++++++++++++++++++
>   drivers/gpu/drm/drm_draw_internal.h |  2 ++
>   drivers/gpu/drm/drm_panic.c         |  2 +-
>   4 files changed, 33 insertions(+), 2 deletions(-)
> ---
> base-commit: ea1013c1539270e372fc99854bc6e4d94eaeff66
> change-id: 20251003-drm_draw_conv_check-9cc3050ebd57
> 
> Best regards,