mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: Lyude Paul <lyude@redhat.com>, David Airlie <airlied@gmail.com>,
	Simona Vetter <simona@ffwll.ch>, Ben Skeggs <bskeggs@redhat.com>,
	Pierre Moreau <pierre.morrow@free.fr>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	Philip Li <philip.li@intel.com>,
	dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, kernel test robot <lkp@intel.com>,
	Timur Tabi <ttabi@nvidia.com>
Subject: Re: [PATCH v2] drm/nouveau/bl: increase buffer size to avoid truncate warning
Date: Fri, 13 Jun 2025 17:46:38 +0200	[thread overview]
Message-ID: <d1b19770-dbee-47d0-a146-409de76dee42@kernel.org> (raw)
In-Reply-To: <20250610-jk-nouveua-drm-bl-snprintf-fix-v2-1-7fdd4b84b48e@intel.com>

On 6/10/25 11:54 PM, Jacob Keller wrote:
> The nouveau_get_backlight_name() function generates a unique name for the
> backlight interface, appending an id from 1 to 99 for all backlight devices
> after the first.
> 
> GCC 15 (and likely other compilers) produce the following
> -Wformat-truncation warning:
> 
> nouveau_backlight.c: In function ‘nouveau_backlight_init’:
> nouveau_backlight.c:56:69: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 3 [-Werror=format-truncation=]
>     56 |                 snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb);
>        |                                                                     ^~
> In function ‘nouveau_get_backlight_name’,
>      inlined from ‘nouveau_backlight_init’ at nouveau_backlight.c:351:7:
> nouveau_backlight.c:56:56: note: directive argument in the range [1, 2147483647]
>     56 |                 snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb);
>        |                                                        ^~~~~~~~~~~~~~~~
> nouveau_backlight.c:56:17: note: ‘snprintf’ output between 14 and 23 bytes into a destination of size 15
>     56 |                 snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb);
>        |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> The warning started appearing after commit ab244be47a8f ("drm/nouveau:
> Fix a potential theorical leak in nouveau_get_backlight_name()") This fix
> for the ida usage removed the explicit value check for ids larger than 99.
> The compiler is unable to intuit that the ida_alloc_max() limits the
> returned value range between 0 and 99.
> 
> Because the compiler can no longer infer that the number ranges from 0 to
> 99, it thinks that it could use as many as 11 digits (10 + the potential -
> sign for negative numbers).
> 
> The warning has gone unfixed for some time, with at least one kernel test
> robot report. The code breaks W=1 builds, which is especially frustrating
> with the introduction of CONFIG_WERROR.
> 
> The string is stored temporarily on the stack and then copied into the
> device name. Its not a big deal to use 11 more bytes of stack rounding out
> to an even 24 bytes. Increase BL_NAME_SIZE to 24 to avoid the truncation
> warning. This fixes the W=1 builds that include this driver.
> 
> Compile tested only.
> 
> Fixes: ab244be47a8f ("drm/nouveau: Fix a potential theorical leak in nouveau_get_backlight_name()")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312050324.0kv4PnfZ-lkp@intel.com/
> Suggested-by: Timur Tabi <ttabi@nvidia.com>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>

Applied to drm-misc-fixes, thanks!

      reply	other threads:[~2025-06-13 15:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-10 21:54 Jacob Keller
2025-06-13 15:46 ` Danilo Krummrich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d1b19770-dbee-47d0-a146-409de76dee42@kernel.org \
    --to=dakr@kernel.org \
    --cc=airlied@gmail.com \
    --cc=bskeggs@redhat.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jacob.e.keller@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=lyude@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=philip.li@intel.com \
    --cc=pierre.morrow@free.fr \
    --cc=simona@ffwll.ch \
    --cc=ttabi@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®