Building resctrl with extra checks ("W=12") produces the following warning:
 .../include/linux/ucopysize.h:22:17: warning: ‘buf’ may be used uninitialized [-Wmaybe-uninitialized]
   22 |                 __check_object_size(ptr, n, to_user);
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 .../include/linux/ucopysize.h: In function ‘pseudo_lock_measure_trigger’:
 .../include/linux/ucopysize.h:10:13: note: by argument 1 of type ‘const void *’ to ‘__check_object_size’ declared here
   10 | extern void __check_object_size(const void *ptr, unsigned long n,
      |             ^~~~~~~~~~~~~~~~~~~
 .../fs/resctrl/pseudo_lock.c:754:14: note: ‘buf’ declared here
  754 |         char buf[32];
      |              ^~~

__check_object_size() ensures the provided buffer is within a valid location
but does not read from the uninitialized buffer. Even so, initialize the
buffer to silence the warning to help resctrl have a cleaner build.

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
 fs/resctrl/pseudo_lock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/resctrl/pseudo_lock.c b/fs/resctrl/pseudo_lock.c
index fa3687d69ebd..e1e9134474f4 100644
--- a/fs/resctrl/pseudo_lock.c
+++ b/fs/resctrl/pseudo_lock.c
@@ -750,8 +750,8 @@ static ssize_t pseudo_lock_measure_trigger(struct file *file,
 					   size_t count, loff_t *ppos)
 {
 	struct rdtgroup *rdtgrp = file->private_data;
+	char buf[32] = {};
 	size_t buf_size;
-	char buf[32];
 	int ret;
 	int sel;
 
-- 
2.50.1

On Tue, Apr 07, 2026 at 09:02:00AM -0700, Reinette Chatre wrote:
> Building resctrl with extra checks ("W=12") produces the following warning:
>  .../include/linux/ucopysize.h:22:17: warning: ‘buf’ may be used uninitialized [-Wmaybe-uninitialized]
>    22 |                 __check_object_size(ptr, n, to_user);
>       |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  .../include/linux/ucopysize.h: In function ‘pseudo_lock_measure_trigger’:
>  .../include/linux/ucopysize.h:10:13: note: by argument 1 of type ‘const void *’ to ‘__check_object_size’ declared here
>    10 | extern void __check_object_size(const void *ptr, unsigned long n,
>       |             ^~~~~~~~~~~~~~~~~~~
>  .../fs/resctrl/pseudo_lock.c:754:14: note: ‘buf’ declared here
>   754 |         char buf[32];
>       |              ^~~
> 
> __check_object_size() ensures the provided buffer is within a valid location
> but does not read from the uninitialized buffer. Even so, initialize the
> buffer to silence the warning to help resctrl have a cleaner build.
> 
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> ---
>  fs/resctrl/pseudo_lock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/resctrl/pseudo_lock.c b/fs/resctrl/pseudo_lock.c
> index fa3687d69ebd..e1e9134474f4 100644
> --- a/fs/resctrl/pseudo_lock.c
> +++ b/fs/resctrl/pseudo_lock.c
> @@ -750,8 +750,8 @@ static ssize_t pseudo_lock_measure_trigger(struct file *file,
>  					   size_t count, loff_t *ppos)
>  {
>  	struct rdtgroup *rdtgrp = file->private_data;
> +	char buf[32] = {};

AFAIU, you're not leaking any uninitialized stack data from that buffer,
right?

If so, why do you care about some silly build warning and are willing to waste
a 32-byte memset on every function entry?

There's a reason those warnings are behind W= ...

:-)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Hi Boris,

Thank you very much for taking a look.

On 4/7/26 11:55 AM, Borislav Petkov wrote:
> On Tue, Apr 07, 2026 at 09:02:00AM -0700, Reinette Chatre wrote:
>> Building resctrl with extra checks ("W=12") produces the following warning:
>>  .../include/linux/ucopysize.h:22:17: warning: ‘buf’ may be used uninitialized [-Wmaybe-uninitialized]
>>    22 |                 __check_object_size(ptr, n, to_user);
>>       |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>  .../include/linux/ucopysize.h: In function ‘pseudo_lock_measure_trigger’:
>>  .../include/linux/ucopysize.h:10:13: note: by argument 1 of type ‘const void *’ to ‘__check_object_size’ declared here
>>    10 | extern void __check_object_size(const void *ptr, unsigned long n,
>>       |             ^~~~~~~~~~~~~~~~~~~
>>  .../fs/resctrl/pseudo_lock.c:754:14: note: ‘buf’ declared here
>>   754 |         char buf[32];
>>       |              ^~~
>>
>> __check_object_size() ensures the provided buffer is within a valid location
>> but does not read from the uninitialized buffer. Even so, initialize the
>> buffer to silence the warning to help resctrl have a cleaner build.
>>
>> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
>> ---
>>  fs/resctrl/pseudo_lock.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/resctrl/pseudo_lock.c b/fs/resctrl/pseudo_lock.c
>> index fa3687d69ebd..e1e9134474f4 100644
>> --- a/fs/resctrl/pseudo_lock.c
>> +++ b/fs/resctrl/pseudo_lock.c
>> @@ -750,8 +750,8 @@ static ssize_t pseudo_lock_measure_trigger(struct file *file,
>>  					   size_t count, loff_t *ppos)
>>  {
>>  	struct rdtgroup *rdtgrp = file->private_data;
>> +	char buf[32] = {};
> 
> AFAIU, you're not leaking any uninitialized stack data from that buffer,
> right?

Right. From what I can tell __check_object_size() just checks that the address
is from a valid region and does not read from the buffer.

> 
> If so, why do you care about some silly build warning and are willing to waste
> a 32-byte memset on every function entry?

I care because I am including a W=12 build as part of checking all resctrl patches
and having this be the one and only warning that always shows up is distracting.
Removing it to accomplish a clean W=12 build does not seem impactful to me.

Of course you are right that this wastes a memset. This function is not on a
hot path though and I do not believe it would be called frequently since it is
intended to demonstrate how successful the setup of a pseudo-lock region was and
successive calls should produce consistent results.

> 
> There's a reason those warnings are behind W= ...

Indeed. This patch is for developer and maintenance convenience and not required for
resctrl health. No problem from me if you find it not to be appropriate. I will just
continue to parse the warning out of the logs.

Reinette

On Tue, Apr 07, 2026 at 01:50:50PM -0700, Reinette Chatre wrote:
> Indeed. This patch is for developer and maintenance convenience and not required for
> resctrl health. No problem from me if you find it not to be appropriate. I will just
> continue to parse the warning out of the logs.

Oh, your call. I just think it is unnecessary especially because those
warnings are not really worth to care for as they produce a bunch of false
positives and that's why they're not enabled by default.

IOW, I take them with a grain of salt.

In this particular case, I would care about the code not doing any unnecessary
work if it can be helped. And the warning can take a hike... :-)

But I can apply the patch if you prefer.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Hi Boris,

On 4/7/26 3:19 PM, Borislav Petkov wrote:
> 
> In this particular case, I would care about the code not doing any unnecessary
> work if it can be helped. And the warning can take a hike... :-)

This is very convincing. 

> But I can apply the patch if you prefer.

I don't. I'm ok for this to be dropped.

Thank you very much.

Reinette