All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yu, Lang" <Lang.Yu@amd.com>
To: Joe Perches <joe@perches.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] sysfs: Remove page boundary align limitation on sysfs_emit and sysfs_emit_at
Date: Thu, 9 Sep 2021 05:52:23 +0000	[thread overview]
Message-ID: <DM6PR12MB4250AE8DF451484884B657C9FBD59@DM6PR12MB4250.namprd12.prod.outlook.com> (raw)
In-Reply-To: <685524a360bc910210cbbb7b13a46ead26ed8a22.camel@perches.com>

[Public]



>-----Original Message-----
>From: Joe Perches <joe@perches.com>
>Sent: Thursday, September 9, 2021 1:44 PM
>To: Yu, Lang <Lang.Yu@amd.com>; Greg Kroah-Hartman
><gregkh@linuxfoundation.org>; Rafael J . Wysocki <rafael@kernel.org>; linux-
>kernel@vger.kernel.org
>Subject: Re: [PATCH] sysfs: Remove page boundary align limitation on sysfs_emit
>and sysfs_emit_at
>
>On Thu, 2021-09-09 at 05:27 +0000, Yu, Lang wrote:
>> [AMD Official Use Only]
>
>this is a public list and this marker is not appropriate.

Sorry for that.
>
>> > -----Original Message-----
>> > From: Joe Perches <joe@perches.com>
>> > On Wed, 2021-09-08 at 20:07 +0800, Lang Yu wrote:
>> > > The key purpose of sysfs_emit and sysfs_emit_at is to ensure that
>> > > no overrun is done. Make them more equivalent with scnprintf.
>> >
>> > I can't think of a single reason to do this.
>> > sysfs_emit and sysfs_emit_at are specific to sysfs.
>> >
>> > Use of these functions outside of sysfs is not desired or supported.
>> >
>> Thanks for your reply. But I'm still curious why you put such a limitation.
>> As "Documentation/filesystems/sysfs.rst" described, we can just  use
>> scnprintf(buf, PAGE_SIZE, "%s\n", dev->name) in show functions without
>> such a limitation.
>
>There's nothing particularly wrong with the use of scnprintf as above.
>
>The only real reason that sysfs_emit exists is to be able to reduce the kernel
>treewide quantity of uses of the sprintf family of functions that need to be
>analyzed for possible buffer overruns.
>
>The issue there is that buf is already known to be both a PAGE_SIZE buffer and
>PAGE_SIZE aligned for sysfs show functions so there's no real reason to use
>scnprintf.
>
>sysfs_emit is a shorter/smaller function and using it could avoid some sprintf
>defects.
>
>> Some guys just try to replace scnprintf with sysfs_emit() or sysfs_emit_at() per
>above documents.
>
>So don't do that.
>
>> But sprintf and sysfs_emit/sysfs_emit_at are not totally equivalent(e.g., page
>boundary align).
>>
>> In my opinion, we add a new api and try to replace an old api. Does we
>> need to make it more compatible with old api?
>
>IMO: no.
>
But why you said " - show() should only use sysfs_emit() or sysfs_emit_at() when formatting
the value to be returned to user space. " in Documentation/filesystems/sysfs.rst ?

Obviously, sysfs_emit() and sysfs_emit_at()  can't cover all the cases in show functions. 

Regards,
Lang


  reply	other threads:[~2021-09-09  5:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-08 12:07 [PATCH] sysfs: Remove page boundary align limitation on sysfs_emit and sysfs_emit_at Lang Yu
2021-09-08 12:32 ` Greg Kroah-Hartman
2021-09-08 12:52   ` Yu, Lang
2021-09-08 13:04     ` Greg Kroah-Hartman
2021-09-08 13:21       ` Yu, Lang
2021-09-08 13:49         ` Greg Kroah-Hartman
2021-09-08 15:33           ` Yu, Lang
2021-09-09  5:19             ` Greg Kroah-Hartman
2021-09-09  5:31               ` Yu, Lang
2021-09-09  6:05                 ` Greg Kroah-Hartman
2021-09-09  5:05 ` Joe Perches
2021-09-09  5:27   ` Yu, Lang
2021-09-09  5:34     ` Greg Kroah-Hartman
2021-09-09  5:59       ` Yu, Lang
2021-09-09  6:07         ` Greg Kroah-Hartman
2021-09-09  5:44     ` Joe Perches
2021-09-09  5:52       ` Yu, Lang [this message]
2021-09-09  6:07         ` Greg Kroah-Hartman
2021-09-09  6:22           ` Yu, Lang
2021-09-09  6:35             ` Greg Kroah-Hartman
2021-09-09  7:48               ` Yu, Lang
2021-09-09  7:59                 ` Greg Kroah-Hartman
2021-09-09  8:48                   ` Yu, Lang

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=DM6PR12MB4250AE8DF451484884B657C9FBD59@DM6PR12MB4250.namprd12.prod.outlook.com \
    --to=lang.yu@amd.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=joe@perches.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.