From: David Laight <david.laight.linux@gmail.com>
To: Dan Carpenter <error27@gmail.com>
Cc: Mohammad Davoudi <mdavoudi2011@gmail.com>,
johan@kernel.org, elder@kernel.org, gregkh@linuxfoundation.org,
rmfrfs@gmail.com, greybus-dev@lists.linaro.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: greybus: Replace sprintf with sysfs_emit
Date: Thu, 16 Jul 2026 10:47:32 +0100 [thread overview]
Message-ID: <20260716104732.7123b1cd@pumpkin> (raw)
In-Reply-To: <alf8N5msXi95aQfB@stanley.mountain>
On Thu, 16 Jul 2026 00:31:35 +0300
Dan Carpenter <error27@gmail.com> wrote:
> On Wed, Jul 15, 2026 at 05:28:58PM +0000, Mohammad Davoudi wrote:
> > Replace sprintf() with sysfs_emit() in sysfs show functions.
> > The sprintf() function is unaware of the PAGE_SIZE limit of the sysfs
> > buffer, which can potentially lead to buffer overruns. sysfs_emit()
> > is strictly designed for sysfs attributes and inherently protects
> > against buffer boundaries.
> >
> > Signed-off-by: Mohammad Davoudi <MDavoudi2011@gmail.com>
>
> We're not applying this kind of patch in cases where sprintf is fine.
>
> Really, I never like commit messages which talk about "potential
> buffer overruns". Is it a buffer overrun or not? If it's really
> hard to figure out then say that "This code is really hard to figure
> out and I suspect its fine but let's be safe."
>
> In this case the code is really simple and we can all see the original
> code is fine just from reading the diff...
And you also have to double-check that it is valid to call sysfs_emit()
in that context.
The call sequences aren't all that obvious and are difficult to verify.
David
>
> regards,
> dan carpenter
>
>
prev parent reply other threads:[~2026-07-16 9:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 17:28 [PATCH] staging: greybus: Replace sprintf with sysfs_emit Mohammad Davoudi
2026-07-15 21:31 ` Dan Carpenter
2026-07-16 9:47 ` David Laight [this message]
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=20260716104732.7123b1cd@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=elder@kernel.org \
--cc=error27@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=greybus-dev@lists.linaro.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=mdavoudi2011@gmail.com \
--cc=rmfrfs@gmail.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.