From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sysfs: make sysfs_emit() return ssize_t
Date: Fri, 8 Mar 2024 09:01:24 +0000 [thread overview]
Message-ID: <2024030803-bulk-grader-3ad1@gregkh> (raw)
In-Reply-To: <f57ab790-d0a5-4454-977b-9bdc146e6e93@p183>
On Fri, Mar 08, 2024 at 09:26:01AM +0300, Alexey Dobriyan wrote:
> On Thu, Mar 07, 2024 at 10:04:41PM +0000, Greg Kroah-Hartman wrote:
> > On Mon, Feb 05, 2024 at 01:11:36PM +0300, Alexey Dobriyan wrote:
> > > sysfs_emit() is most often found in functions returning ssize_t
> > > not int:
> > >
> > > static ssize_t oops_count_show(...)
> > > {
> > > return sysfs_emit(page, ...);
> > > }
> > >
> > > This pattern results in sign-extension instruction between
> > > sysfs_emit() return value (int) and caller return value (which is
> > > ssize_t).
> >
> > Is that a problem?
>
> Small problem, but, yes.
>
> If sysfs_emit() returns "int", then every user compiles to
>
> call sysfs_emit
> movsx rax, eax
> ret
>
> Given than sysfs_emit() is the official way to print in sysfs,
> there are lots of users and there will be more users in the future
> as it grows.
>
> This trailing "movsx" instruction is duplicated every time.
>
> If sysfs_emit() returns ssize_t then it is folded into sysfs_emit() and
> appears in the code _once_ saving bytes.
>
> Ultimately, all this confusion and mismatches come from snprintf()
> accepting "size_t" but returning "int" (despite working on very large
> strings!) which sysfs_emit() copied.
True, then why not fix up the base function here, vscnprintf() and
vsnprintf() and then propagate the fixes outward?
thanks,
greg k-h
next prev parent reply other threads:[~2024-03-08 9:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-05 10:11 [PATCH] sysfs: make sysfs_emit() return ssize_t Alexey Dobriyan
2024-03-07 22:04 ` Greg Kroah-Hartman
2024-03-08 6:26 ` Alexey Dobriyan
2024-03-08 9:01 ` Greg Kroah-Hartman [this message]
2024-03-10 19:21 ` David Laight
2024-03-11 4:55 ` Alexey Dobriyan
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=2024030803-bulk-grader-3ad1@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=adobriyan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@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.