From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: <shiju.jose@huawei.com>
Cc: <linux-edac@vger.kernel.org>, <bp@alien8.de>,
<tony.luck@intel.com>, <arnd@kernel.org>, <mchehab@kernel.org>,
<rric@kernel.org>, <dave.jiang@intel.com>, <linuxarm@huawei.com>,
<tanxiaofei@huawei.com>, <prime.zeng@hisilicon.com>
Subject: Re: [PATCH 1/2] EDAC/scrub: Reduce stack usage in scrub_create_desc()
Date: Mon, 30 Jun 2025 18:11:30 +0100 [thread overview]
Message-ID: <20250630181130.000011c9@huawei.com> (raw)
In-Reply-To: <20250630162034.1788-2-shiju.jose@huawei.com>
On Mon, 30 Jun 2025 17:20:33 +0100
<shiju.jose@huawei.com> wrote:
> From: Shiju Jose <shiju.jose@huawei.com>
>
> Constructing an array on the stack can exceed the warning limit
> for per-function stack usage.
>
> Change this to have the actual attribute array allocated statically and
> then add the instance number on the per-instance copy.
>
> Fixes: f90b738166fe ("EDAC: Add scrub control feature")
> Suggested-by: Borislav Petkov (AMD) <bp@alien8.de>
> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> ---
> drivers/edac/scrub.c | 31 +++++++++++--------------------
> 1 file changed, 11 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/edac/scrub.c b/drivers/edac/scrub.c
> index f9d02af2fc3a..850347d274e8 100755
> --- a/drivers/edac/scrub.c
> +++ b/drivers/edac/scrub.c
> @@ -142,17 +142,14 @@ static umode_t scrub_attr_visible(struct kobject *kobj, struct attribute *a, int
> return 0;
> }
>
> -#define EDAC_SCRUB_ATTR_RO(_name, _instance) \
> - ((struct edac_scrub_dev_attr) { .dev_attr = __ATTR_RO(_name), \
> - .instance = _instance })
> -
> -#define EDAC_SCRUB_ATTR_WO(_name, _instance) \
> - ((struct edac_scrub_dev_attr) { .dev_attr = __ATTR_WO(_name), \
> - .instance = _instance })
> -
> -#define EDAC_SCRUB_ATTR_RW(_name, _instance) \
> - ((struct edac_scrub_dev_attr) { .dev_attr = __ATTR_RW(_name), \
> - .instance = _instance })
> +static const struct device_attribute scrub_dev_attr[] = {
> + [SCRUB_ADDRESS] = __ATTR_RW(addr),
> + [SCRUB_SIZE] = __ATTR_RW(size),
> + [SCRUB_ENABLE_BACKGROUND] = __ATTR_RW(enable_background),
> + [SCRUB_MIN_CYCLE_DURATION] = __ATTR_RO(min_cycle_duration),
> + [SCRUB_MAX_CYCLE_DURATION] = __ATTR_RO(max_cycle_duration),
> + [SCRUB_CUR_CYCLE_DURATION] = __ATTR_RW(current_cycle_duration)
> +};
>
> static int scrub_create_desc(struct device *scrub_dev,
> const struct attribute_group **attr_groups, u8 instance)
> @@ -160,14 +157,6 @@ static int scrub_create_desc(struct device *scrub_dev,
> struct edac_scrub_context *scrub_ctx;
> struct attribute_group *group;
> int i;
> - struct edac_scrub_dev_attr dev_attr[] = {
> - [SCRUB_ADDRESS] = EDAC_SCRUB_ATTR_RW(addr, instance),
> - [SCRUB_SIZE] = EDAC_SCRUB_ATTR_RW(size, instance),
> - [SCRUB_ENABLE_BACKGROUND] = EDAC_SCRUB_ATTR_RW(enable_background, instance),
> - [SCRUB_MIN_CYCLE_DURATION] = EDAC_SCRUB_ATTR_RO(min_cycle_duration, instance),
> - [SCRUB_MAX_CYCLE_DURATION] = EDAC_SCRUB_ATTR_RO(max_cycle_duration, instance),
> - [SCRUB_CUR_CYCLE_DURATION] = EDAC_SCRUB_ATTR_RW(current_cycle_duration, instance)
> - };
>
> scrub_ctx = devm_kzalloc(scrub_dev, sizeof(*scrub_ctx), GFP_KERNEL);
> if (!scrub_ctx)
> @@ -175,7 +164,9 @@ static int scrub_create_desc(struct device *scrub_dev,
>
> group = &scrub_ctx->group;
> for (i = 0; i < SCRUB_MAX_ATTRS; i++) {
> - memcpy(&scrub_ctx->scrub_dev_attr[i], &dev_attr[i], sizeof(dev_attr[i]));
> + scrub_ctx->scrub_dev_attr[i].dev_attr = scrub_dev_attr[i];
> + scrub_ctx->scrub_dev_attr[i].instance = instance;
> +
> sysfs_attr_init(&scrub_ctx->scrub_dev_attr[i].dev_attr.attr);
> scrub_ctx->scrub_attrs[i] = &scrub_ctx->scrub_dev_attr[i].dev_attr.attr;
> }
next prev parent reply other threads:[~2025-06-30 17:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-30 16:20 [PATCH 0/2] EDAC/features: Reduce stack usage in create_desc functions shiju.jose
2025-06-30 16:20 ` [PATCH 1/2] EDAC/scrub: Reduce stack usage in scrub_create_desc() shiju.jose
2025-06-30 17:11 ` Jonathan Cameron [this message]
2025-06-30 16:20 ` [PATCH 2/2] EDAC/ecs: Reduce stack usage in ecs_create_desc() shiju.jose
2025-06-30 17:15 ` Jonathan Cameron
2025-07-01 3:27 ` kernel test robot
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=20250630181130.000011c9@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=arnd@kernel.org \
--cc=bp@alien8.de \
--cc=dave.jiang@intel.com \
--cc=linux-edac@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mchehab@kernel.org \
--cc=prime.zeng@hisilicon.com \
--cc=rric@kernel.org \
--cc=shiju.jose@huawei.com \
--cc=tanxiaofei@huawei.com \
--cc=tony.luck@intel.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 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.