From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: "Hegde, Suma" <Suma.Hegde@amd.com>
Cc: platform-driver-x86@vger.kernel.org,
Hans de Goede <hdegoede@redhat.com>,
Naveen Krishna Chatradhi <nchatrad@amd.com>
Subject: Re: [PATCH v4 2/3] platform/x86/amd/hsmp: add support for metrics tbl
Date: Mon, 9 Oct 2023 14:23:18 +0300 (EEST) [thread overview]
Message-ID: <faf39eb5-ac8a-b32a-d6a-a4bb6ea8ab3a@linux.intel.com> (raw)
In-Reply-To: <bb3ec2c2-332e-d6ca-2c06-31d2b68d346b@amd.com>
[-- Attachment #1: Type: text/plain, Size: 3306 bytes --]
On Mon, 9 Oct 2023, Hegde, Suma wrote:
> On 10/6/2023 6:51 PM, Ilpo Järvinen wrote:
> > On Thu, 5 Oct 2023, Suma Hegde wrote:
> >
> > > AMD MI300 MCM provides GET_METRICS_TABLE message to retrieve
> > > all the system management information from SMU.
> > >
> > > The metrics table is made available as hexadecimal sysfs binary file
> > > under per socket sysfs directory created at
> > > /sys/devices/platform/amd_hsmp/socket%d/metrics_bin
> > >
> > > Metrics table definitions will be documented as part of Public PPR.
> > > The same is defined in the amd_hsmp.h header.
> > >
> > > Signed-off-by: Suma Hegde <suma.hegde@amd.com>
> > > Reviewed-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
> >
> > > +static int hsmp_create_sysfs_interface(void)
> > > +{
> > > + const struct attribute_group **hsmp_attr_grps;
> > > + struct bin_attribute **hsmp_bin_attrs;
> > > + struct attribute_group *attr_grp;
> > > + int ret;
> > > + u8 i;
> > > +
> > > + hsmp_attr_grps = devm_kzalloc(plat_dev.dev, sizeof(struct
> > > attribute_group *) *
> > > + (plat_dev.num_sockets + 1),
> > > GFP_KERNEL);
> > > + if (!hsmp_attr_grps)
> > > + return -ENOMEM;
> > > +
> > > + /* Create a sysfs directory for each socket */
> > > + for (i = 0; i < plat_dev.num_sockets; i++) {
> > The change for i to u8 seems not very wise given num_sockets still is u16
> > as it can turn this into an infinite loop.
>
> Hi Ilpo,
>
> amd_nb_num() API which we use to identify the number of sockets on a node
> returns u16. So, we used u16 for plat_dev.num_sockets.
> u8 should be enough, as present AMD processors support upto 8 sockets on a
> node.
I wasn't expecting it to fail at the moment, I just don't want to leave a
silent trap for the future.
> Coming to the warning raised:
> We have defined, HSMP_ATTR_GRP_NAME_SIZE as 10bytes, 6 chars for 'socket', 3
> chars for 3digits (socket index) and a null terminator.
> Socket index may not need more than 3 digits in the foreseeable future. How
> about, we declare i as u16 and typecast it as (u8) in the snprintf.
>
> int ret;
> - u8 i;
> + u16 i;
>
> hsmp_attr_grps = devm_kzalloc(plat_dev.dev, sizeof(struct
> attribute_group *) *
> (plat_dev.num_sockets + 1), GFP_KERNEL); @@
> -449,7 +449,7 @@ static int hsmp_create_sysfs_interface(void)
> if (!attr_grp)
> return -ENOMEM;
>
> - snprintf(plat_dev.sock[i].name, HSMP_ATTR_GRP_NAME_SIZE, "socket%u",
> i);
> + snprintf(plat_dev.sock[i].name, HSMP_ATTR_GRP_NAME_SIZE,
> + "socket%u", (u8)i);
> attr_grp->name = plat_dev.sock[i].name;
This is similarly trappy as it truncates i if num_sockets is > 255.
I suggest you just put this into start of the function:
/* String formatting is currently limited to u8 sockets */
if (WARN_ON(plat_dev.num_sockets > U8_MAX))
return -ERANGE;
to catch the too many sockets case if it is ever going to occur.
And explain in the changelog that u8 is enough for foreseeable future
and the string formatting triggers a warning if unnecessarily large type
is passed to snprintf().
--
i.
next prev parent reply other threads:[~2023-10-09 11:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 5:39 [PATCH v4 1/3] platform/x86/amd/hsmp: create plat specific struct Suma Hegde
2023-10-05 5:39 ` [PATCH v4 2/3] platform/x86/amd/hsmp: add support for metrics tbl Suma Hegde
2023-10-06 13:21 ` Ilpo Järvinen
2023-10-09 5:46 ` Hegde, Suma
2023-10-09 11:23 ` Ilpo Järvinen [this message]
2023-10-09 15:10 ` Hegde, Suma
2023-10-05 5:39 ` [PATCH v4 3/3] platform/x86/amd/hsmp: improve the error log Suma Hegde
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=faf39eb5-ac8a-b32a-d6a-a4bb6ea8ab3a@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=Suma.Hegde@amd.com \
--cc=hdegoede@redhat.com \
--cc=nchatrad@amd.com \
--cc=platform-driver-x86@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.