linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 1623 bytes into a region of size between 32 and 63
@ 2025-07-18  8:39 kernel test robot
  2025-07-18 15:27 ` Joshua Hahn
  0 siblings, 1 reply; 2+ messages in thread
From: kernel test robot @ 2025-07-18  8:39 UTC (permalink / raw)
  To: Xiu Jianfeng
  Cc: oe-kbuild-all, linux-kernel, Andrew Morton,
	Linux Memory Management List

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   6832a9317eee280117cd695fa885b2b7a7a38daf
commit: 47179fe03588caa13a9bae642b058901709ddc55 mm/hugetlb_cgroup: prepare cftypes based on template
date:   1 year ago
config: s390-randconfig-r132-20250718 (https://download.01.org/0day-ci/archive/20250718/202507181808.mpbc1F0r-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 10.5.0
reproduce: (https://download.01.org/0day-ci/archive/20250718/202507181808.mpbc1F0r-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/202507181808.mpbc1F0r-lkp@intel.com/

All warnings (new ones prefixed by >>):

   mm/hugetlb_cgroup.c: In function 'hugetlb_cgroup_file_init':
>> mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 1623 bytes into a region of size between 32 and 63 [-Wformat-truncation=]
     829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
         |                                            ^~
   mm/hugetlb_cgroup.c:829:3: note: 'snprintf' output between 2 and 1656 bytes into a destination of size 64
     829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
         |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 2087 bytes into a region of size between 32 and 63 [-Wformat-truncation=]
     829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
         |                                            ^~
   mm/hugetlb_cgroup.c:829:3: note: 'snprintf' output between 2 and 2120 bytes into a destination of size 64
     829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
         |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


vim +829 mm/hugetlb_cgroup.c

   815	
   816	static void __init
   817	hugetlb_cgroup_cfttypes_init(struct hstate *h, struct cftype *cft,
   818				     struct cftype *tmpl, int tmpl_size)
   819	{
   820		char buf[32];
   821		int i, idx = hstate_index(h);
   822	
   823		/* format the size */
   824		mem_fmt(buf, sizeof(buf), huge_page_size(h));
   825	
   826		for (i = 0; i < tmpl_size; cft++, tmpl++, i++) {
   827			*cft = *tmpl;
   828			/* rebuild the name */
 > 829			snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
   830			/* rebuild the private */
   831			cft->private = MEMFILE_PRIVATE(idx, tmpl->private);
   832			/* rebuild the file_offset */
   833			if (tmpl->file_offset) {
   834				unsigned int offset = tmpl->file_offset;
   835	
   836				cft->file_offset = MEMFILE_OFFSET0(offset) +
   837						   MEMFILE_FIELD_SIZE(offset) * idx;
   838			}
   839	
   840			lockdep_register_key(&cft->lockdep_key);
   841		}
   842	}
   843	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 1623 bytes into a region of size between 32 and 63
  2025-07-18  8:39 mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 1623 bytes into a region of size between 32 and 63 kernel test robot
@ 2025-07-18 15:27 ` Joshua Hahn
  0 siblings, 0 replies; 2+ messages in thread
From: Joshua Hahn @ 2025-07-18 15:27 UTC (permalink / raw)
  To: kernel test robot
  Cc: Xiu Jianfeng, oe-kbuild-all, linux-kernel, Andrew Morton,
	Linux Memory Management List

On Fri, 18 Jul 2025 16:39:59 +0800 kernel test robot <lkp@intel.com> wrote:

>    mm/hugetlb_cgroup.c: In function 'hugetlb_cgroup_file_init':
> >> mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 1623 bytes into a region of size between 32 and 63 [-Wformat-truncation=]
>      829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
>          |                                            ^~
>    mm/hugetlb_cgroup.c:829:3: note: 'snprintf' output between 2 and 1656 bytes into a destination of size 64
>      829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
>          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 2087 bytes into a region of size between 32 and 63 [-Wformat-truncation=]
>      829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
>          |                                            ^~
>    mm/hugetlb_cgroup.c:829:3: note: 'snprintf' output between 2 and 2120 bytes into a destination of size 64
>      829 |   snprintf(cft->name, MAX_CFTYPE_NAME, "%s.%s", buf, tmpl->name);
>          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In theory,

#define MAX_CFTYPE_NAME = 64
sizeof(cft->name) = MAX_CFTYPE_NAME
sizeof(buf) = 32
sizeof(tmpl->name) = MAX_CFTYPE_NAME

But in practice there should never really be an overflow, since the longest
name so far "rsvd.max_usage_in_bytes" is 23 characters long and the longest
hugepage size string is "64KB" or "32MB"...

Unless someone makes a horrendously long name, I think we should be good.
With that said, char *mem_fmt only returns strings of up to 4 characters long.
Maybe we can shrink sizeof(buf) to be 4 and explicitly truncate the last
5 bytes (account for '.') of tmpl->name? I can spin something up.

Curious what others think though. Is this fix necessary? We really should
never overflow anyways.

Thank you Kernel Test Robot!
Joshua

Sent using hkml (https://github.com/sjp38/hackermail)


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-07-18 15:27 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-18  8:39 mm/hugetlb_cgroup.c:829:44: warning: '%s' directive output may be truncated writing up to 1623 bytes into a region of size between 32 and 63 kernel test robot
2025-07-18 15:27 ` Joshua Hahn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).