* drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12
@ 2025-01-29 8:08 kernel test robot
2025-01-29 12:45 ` Andy Shevchenko
0 siblings, 1 reply; 7+ messages in thread
From: kernel test robot @ 2025-01-29 8:08 UTC (permalink / raw)
To: Maximilian Luz
Cc: llvm, oe-kbuild-all, linux-kernel, Hans de Goede, Andy Shevchenko
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 05dbaf8dd8bf537d4b4eb3115ab42a5fb40ff1f5
commit: 85f7582cd484dbf491b6d9bb2af6ef1467a024d2 platform/surface: Move Surface 3 Power OpRegion driver to platform/surface
date: 4 years, 3 months ago
config: x86_64-randconfig-071-20241231 (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/config)
compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202501291646.VtwF98qd-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Wformat-truncation-non-kprintf]
243 | snprintf(bix->serial, ARRAY_SIZE(bix->serial), "%3pE%6pE", buf + 7, buf);
| ^
1 warning generated.
vim +/snprintf +243 drivers/platform/surface/surface3_power.c
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 207
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 208 static int mshw0011_bix(struct mshw0011_data *cdata, struct bix *bix)
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 209 {
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 210 struct i2c_client *client = cdata->bat0;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 211 char buf[SURFACE_3_STRLEN];
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 212 int ret;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 213
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 214 *bix = default_bix;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 215
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 216 /* get design capacity */
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 217 ret = i2c_smbus_read_word_data(client,
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 218 MSHW0011_BAT0_REG_DESIGN_CAPACITY);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 219 if (ret < 0) {
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 220 dev_err(&client->dev, "Error reading design capacity: %d\n",
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 221 ret);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 222 return ret;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 223 }
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 224 bix->design_capacity = ret;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 225
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 226 /* get last full charge capacity */
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 227 ret = i2c_smbus_read_word_data(client,
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 228 MSHW0011_BAT0_REG_FULL_CHG_CAPACITY);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 229 if (ret < 0) {
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 230 dev_err(&client->dev,
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 231 "Error reading last full charge capacity: %d\n", ret);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 232 return ret;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 233 }
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 234 bix->last_full_charg_capacity = ret;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 235
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 236 /* get serial number */
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 237 ret = i2c_smbus_read_i2c_block_data(client, MSHW0011_BAT0_REG_SERIAL_NO,
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 238 sizeof(buf), buf);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 239 if (ret != sizeof(buf)) {
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 240 dev_err(&client->dev, "Error reading serial no: %d\n", ret);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 241 return ret;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 242 }
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 @243 snprintf(bix->serial, ARRAY_SIZE(bix->serial), "%3pE%6pE", buf + 7, buf);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 244
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 245 /* get cycle count */
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 246 ret = i2c_smbus_read_word_data(client, MSHW0011_BAT0_REG_CYCLE_CNT);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 247 if (ret < 0) {
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 248 dev_err(&client->dev, "Error reading cycle count: %d\n", ret);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 249 return ret;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 250 }
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 251 bix->cycle_count = ret;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 252
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 253 /* get OEM name */
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 254 ret = i2c_smbus_read_i2c_block_data(client, MSHW0011_BAT0_REG_OEM,
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 255 4, buf);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 256 if (ret != 4) {
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 257 dev_err(&client->dev, "Error reading cycle count: %d\n", ret);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 258 return ret;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 259 }
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 260 snprintf(bix->OEM, ARRAY_SIZE(bix->OEM), "%3pE", buf);
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 261
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 262 return 0;
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 263 }
b1f81b496b0d14 drivers/platform/x86/surface3_power.c Blaž Hrastnik 2020-03-21 264
:::::: The code at line 243 was first introduced by commit
:::::: b1f81b496b0d14382a9cf160cc4dbdefb233f936 platform/x86: surface3_power: MSHW0011 rev-eng implementation
:::::: TO: Blaž Hrastnik <blaz@mxxn.io>
:::::: CC: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12
2025-01-29 8:08 drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 kernel test robot
@ 2025-01-29 12:45 ` Andy Shevchenko
2025-01-29 12:50 ` Andy Shevchenko
2025-01-29 13:46 ` Nathan Chancellor
0 siblings, 2 replies; 7+ messages in thread
From: Andy Shevchenko @ 2025-01-29 12:45 UTC (permalink / raw)
To: kernel test robot
Cc: Maximilian Luz, llvm, oe-kbuild-all, linux-kernel, Hans de Goede
On Wed, Jan 29, 2025 at 10:09 AM kernel test robot <lkp@intel.com> wrote:
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 05dbaf8dd8bf537d4b4eb3115ab42a5fb40ff1f5
> commit: 85f7582cd484dbf491b6d9bb2af6ef1467a024d2 platform/surface: Move Surface 3 Power OpRegion driver to platform/surface
> date: 4 years, 3 months ago
> config: x86_64-randconfig-071-20241231 (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/config)
> compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202501291646.VtwF98qd-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
> >> drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Wformat-truncation-non-kprintf]
> 243 | snprintf(bix->serial, ARRAY_SIZE(bix->serial), "%3pE%6pE", buf + 7, buf);
3 + 'E' + 6 + 'E' + NUL, that's how the compiler thinks about this
formatting string...
> | ^
> 1 warning generated.
I do not know how to properly address this because it's false positive
due to the compiler not being aware of pointer extensions used in
Linux kernel. The w/a is to increase the buffer if we can, but is it
practical? OTOH, this warning will be translated to a compilation
error in case of default WERROR settings on `make W=1` builds which is
also annoying to people what want have that clean.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12
2025-01-29 12:45 ` Andy Shevchenko
@ 2025-01-29 12:50 ` Andy Shevchenko
2025-01-30 8:56 ` Geert Uytterhoeven
2025-01-29 13:46 ` Nathan Chancellor
1 sibling, 1 reply; 7+ messages in thread
From: Andy Shevchenko @ 2025-01-29 12:50 UTC (permalink / raw)
To: kernel test robot
Cc: Maximilian Luz, llvm, oe-kbuild-all, linux-kernel, Hans de Goede
On Wed, Jan 29, 2025 at 2:45 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Wed, Jan 29, 2025 at 10:09 AM kernel test robot <lkp@intel.com> wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head: 05dbaf8dd8bf537d4b4eb3115ab42a5fb40ff1f5
> > commit: 85f7582cd484dbf491b6d9bb2af6ef1467a024d2 platform/surface: Move Surface 3 Power OpRegion driver to platform/surface
> > date: 4 years, 3 months ago
> > config: x86_64-randconfig-071-20241231 (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/config)
> > compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/reproduce)
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202501291646.VtwF98qd-lkp@intel.com/
> >
> > All warnings (new ones prefixed by >>):
> >
> > >> drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Wformat-truncation-non-kprintf]
> > 243 | snprintf(bix->serial, ARRAY_SIZE(bix->serial), "%3pE%6pE", buf + 7, buf);
>
> 3 + 'E' + 6 + 'E' + NUL, that's how the compiler thinks about this
> formatting string...
>
> > | ^
> > 1 warning generated.
>
> I do not know how to properly address this because it's false positive
> due to the compiler not being aware of pointer extensions used in
> Linux kernel. The w/a is to increase the buffer if we can, but is it
> practical? OTOH, this warning will be translated to a compilation
> error in case of default WERROR settings on `make W=1` builds which is
> also annoying to people who want to have that clean.
Actually using %pE implies that the buffer should be 4 times bigger
than the input string. So, with the given format string the
ARRAY_SIZE(bix->serial) has to be equal to or greater than 3 * 4 + 6 *
4 + 1, i.e. 37.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12
2025-01-29 12:45 ` Andy Shevchenko
2025-01-29 12:50 ` Andy Shevchenko
@ 2025-01-29 13:46 ` Nathan Chancellor
2025-01-29 22:16 ` David Laight
1 sibling, 1 reply; 7+ messages in thread
From: Nathan Chancellor @ 2025-01-29 13:46 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann
Cc: kernel test robot, Maximilian Luz, llvm, oe-kbuild-all,
linux-kernel, Hans de Goede
On Wed, Jan 29, 2025 at 02:45:38PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 29, 2025 at 10:09 AM kernel test robot <lkp@intel.com> wrote:
> >
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head: 05dbaf8dd8bf537d4b4eb3115ab42a5fb40ff1f5
> > commit: 85f7582cd484dbf491b6d9bb2af6ef1467a024d2 platform/surface: Move Surface 3 Power OpRegion driver to platform/surface
> > date: 4 years, 3 months ago
> > config: x86_64-randconfig-071-20241231 (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/config)
> > compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/reproduce)
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202501291646.VtwF98qd-lkp@intel.com/
> >
> > All warnings (new ones prefixed by >>):
> >
> > >> drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Wformat-truncation-non-kprintf]
> > 243 | snprintf(bix->serial, ARRAY_SIZE(bix->serial), "%3pE%6pE", buf + 7, buf);
>
> 3 + 'E' + 6 + 'E' + NUL, that's how the compiler thinks about this
> formatting string...
>
> > | ^
> > 1 warning generated.
>
> I do not know how to properly address this because it's false positive
> due to the compiler not being aware of pointer extensions used in
> Linux kernel. The w/a is to increase the buffer if we can, but is it
> practical? OTOH, this warning will be translated to a compilation
> error in case of default WERROR settings on `make W=1` builds which is
> also annoying to people what want have that clean.
Hmmm, I missed that -Wformat-truncation-non-kprintf was only disabled in
the non-W=1 block in scripts/Makefile.extrawarn. We never want to see
these warnings at any level because they will almost always be a false
positive, that's why the "non-kprintf" flags even exist in the first
place:
https://github.com/llvm/llvm-project/pull/65969
I suspect we want something like this.
diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 1d13cecc7cc7..8878f71463fc 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -31,6 +31,11 @@ KBUILD_CFLAGS-$(CONFIG_CC_NO_ARRAY_BOUNDS) += -Wno-array-bounds
ifdef CONFIG_CC_IS_CLANG
# The kernel builds with '-std=gnu11' so use of GNU extensions is acceptable.
KBUILD_CFLAGS += -Wno-gnu
+
+# Clang checks for overflow/truncation with '%p', while GCC does not:
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111219
+KBUILD_CFLAGS += $(call cc-disable-warning, format-overflow-non-kprintf)
+KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation-non-kprintf)
else
# gcc inanely warns about local variables called 'main'
@@ -102,11 +107,6 @@ KBUILD_CFLAGS += $(call cc-disable-warning, packed-not-aligned)
KBUILD_CFLAGS += $(call cc-disable-warning, format-overflow)
ifdef CONFIG_CC_IS_GCC
KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
-else
-# Clang checks for overflow/truncation with '%p', while GCC does not:
-# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111219
-KBUILD_CFLAGS += $(call cc-disable-warning, format-overflow-non-kprintf)
-KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation-non-kprintf)
endif
KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12
2025-01-29 13:46 ` Nathan Chancellor
@ 2025-01-29 22:16 ` David Laight
0 siblings, 0 replies; 7+ messages in thread
From: David Laight @ 2025-01-29 22:16 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Andy Shevchenko, Arnd Bergmann, kernel test robot, Maximilian Luz,
llvm, oe-kbuild-all, linux-kernel, Hans de Goede
On Wed, 29 Jan 2025 06:46:48 -0700
Nathan Chancellor <nathan@kernel.org> wrote:
> On Wed, Jan 29, 2025 at 02:45:38PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 29, 2025 at 10:09 AM kernel test robot <lkp@intel.com> wrote:
> > >
> > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > head: 05dbaf8dd8bf537d4b4eb3115ab42a5fb40ff1f5
> > > commit: 85f7582cd484dbf491b6d9bb2af6ef1467a024d2 platform/surface: Move Surface 3 Power OpRegion driver to platform/surface
> > > date: 4 years, 3 months ago
> > > config: x86_64-randconfig-071-20241231 (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/config)
> > > compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/reproduce)
> > >
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202501291646.VtwF98qd-lkp@intel.com/
> > >
> > > All warnings (new ones prefixed by >>):
> > >
> > > >> drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Wformat-truncation-non-kprintf]
> > > 243 | snprintf(bix->serial, ARRAY_SIZE(bix->serial), "%3pE%6pE", buf + 7, buf);
> >
> > 3 + 'E' + 6 + 'E' + NUL, that's how the compiler thinks about this
> > formatting string...
> >
> > > | ^
> > > 1 warning generated.
> >
> > I do not know how to properly address this because it's false positive
> > due to the compiler not being aware of pointer extensions used in
> > Linux kernel. The w/a is to increase the buffer if we can, but is it
> > practical? OTOH, this warning will be translated to a compilation
> > error in case of default WERROR settings on `make W=1` builds which is
> > also annoying to people what want have that clean.
>
> Hmmm, I missed that -Wformat-truncation-non-kprintf was only disabled in
> the non-W=1 block in scripts/Makefile.extrawarn. We never want to see
> these warnings at any level because they will almost always be a false
> positive, that's why the "non-kprintf" flags even exist in the first
> place:
...
There is a separate issue that it doesn't seem to be easy to mark a specific
snprintf() as one that will not actually overflow or where truncation is fine.
Persuading the compiler that the buffer size isn't constant currently works,
but I expect the compiler will start double checking against ARRAY_SIZE(buffer)
'any time soon' which will require the same treatment applied to the buffer
address.
David
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12
2025-01-29 12:50 ` Andy Shevchenko
@ 2025-01-30 8:56 ` Geert Uytterhoeven
2025-01-30 16:50 ` Andy Shevchenko
0 siblings, 1 reply; 7+ messages in thread
From: Geert Uytterhoeven @ 2025-01-30 8:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: kernel test robot, Maximilian Luz, llvm, oe-kbuild-all,
linux-kernel, Hans de Goede
On Wed, 29 Jan 2025 at 13:51, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Wed, Jan 29, 2025 at 2:45 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Wed, Jan 29, 2025 at 10:09 AM kernel test robot <lkp@intel.com> wrote:
>
> > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > head: 05dbaf8dd8bf537d4b4eb3115ab42a5fb40ff1f5
> > > commit: 85f7582cd484dbf491b6d9bb2af6ef1467a024d2 platform/surface: Move Surface 3 Power OpRegion driver to platform/surface
> > > date: 4 years, 3 months ago
> > > config: x86_64-randconfig-071-20241231 (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/config)
> > > compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/reproduce)
> > >
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202501291646.VtwF98qd-lkp@intel.com/
> > >
> > > All warnings (new ones prefixed by >>):
> > >
> > > >> drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Wformat-truncation-non-kprintf]
> > > 243 | snprintf(bix->serial, ARRAY_SIZE(bix->serial), "%3pE%6pE", buf + 7, buf);
> >
> > 3 + 'E' + 6 + 'E' + NUL, that's how the compiler thinks about this
> > formatting string...
> >
> > > | ^
> > > 1 warning generated.
> >
> > I do not know how to properly address this because it's false positive
> > due to the compiler not being aware of pointer extensions used in
> > Linux kernel. The w/a is to increase the buffer if we can, but is it
> > practical? OTOH, this warning will be translated to a compilation
> > error in case of default WERROR settings on `make W=1` builds which is
> > also annoying to people who want to have that clean.
>
> Actually using %pE implies that the buffer should be 4 times bigger
> than the input string. So, with the given format string the
> ARRAY_SIZE(bix->serial) has to be equal to or greater than 3 * 4 + 6 *
> 4 + 1, i.e. 37.
#define SURFACE_3_STRLEN 10
struct bix {
...
char serial[SURFACE_3_STRLEN];
Oops...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12
2025-01-30 8:56 ` Geert Uytterhoeven
@ 2025-01-30 16:50 ` Andy Shevchenko
0 siblings, 0 replies; 7+ messages in thread
From: Andy Shevchenko @ 2025-01-30 16:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: kernel test robot, Maximilian Luz, llvm, oe-kbuild-all,
linux-kernel, Hans de Goede
On Thu, Jan 30, 2025 at 10:57 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Wed, 29 Jan 2025 at 13:51, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Wed, Jan 29, 2025 at 2:45 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Wed, Jan 29, 2025 at 10:09 AM kernel test robot <lkp@intel.com> wrote:
> >
> > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > > head: 05dbaf8dd8bf537d4b4eb3115ab42a5fb40ff1f5
> > > > commit: 85f7582cd484dbf491b6d9bb2af6ef1467a024d2 platform/surface: Move Surface 3 Power OpRegion driver to platform/surface
> > > > date: 4 years, 3 months ago
> > > > config: x86_64-randconfig-071-20241231 (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/config)
> > > > compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
> > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250129/202501291646.VtwF98qd-lkp@intel.com/reproduce)
> > > >
> > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > > the same patch/commit), kindly add following tags
> > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202501291646.VtwF98qd-lkp@intel.com/
> > > >
> > > > All warnings (new ones prefixed by >>):
> > > >
> > > > >> drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Wformat-truncation-non-kprintf]
> > > > 243 | snprintf(bix->serial, ARRAY_SIZE(bix->serial), "%3pE%6pE", buf + 7, buf);
> > >
> > > 3 + 'E' + 6 + 'E' + NUL, that's how the compiler thinks about this
> > > formatting string...
> > >
> > > > | ^
> > > > 1 warning generated.
> > >
> > > I do not know how to properly address this because it's false positive
> > > due to the compiler not being aware of pointer extensions used in
> > > Linux kernel. The w/a is to increase the buffer if we can, but is it
> > > practical? OTOH, this warning will be translated to a compilation
> > > error in case of default WERROR settings on `make W=1` builds which is
> > > also annoying to people who want to have that clean.
> >
> > Actually using %pE implies that the buffer should be 4 times bigger
> > than the input string. So, with the given format string the
> > ARRAY_SIZE(bix->serial) has to be equal to or greater than 3 * 4 + 6 *
> > 4 + 1, i.e. 37.
>
> #define SURFACE_3_STRLEN 10
>
> struct bix {
> ...
> char serial[SURFACE_3_STRLEN];
>
> Oops...
It works because IRL we haven't seen the broken strings that %pE
escapes with help of an octal code. But if one doesn't trust that
input and uses %pE they should provide enough buffer for that
translation to happen.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-01-30 16:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-29 8:08 drivers/platform/surface/surface3_power.c:243:2: warning: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 kernel test robot
2025-01-29 12:45 ` Andy Shevchenko
2025-01-29 12:50 ` Andy Shevchenko
2025-01-30 8:56 ` Geert Uytterhoeven
2025-01-30 16:50 ` Andy Shevchenko
2025-01-29 13:46 ` Nathan Chancellor
2025-01-29 22:16 ` David Laight
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox