All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Yu, Lang" <Lang.Yu@amd.com>
Cc: Joe Perches <joe@perches.com>,
	"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 07:19:25 +0200	[thread overview]
Message-ID: <YTmZXU7myBFjx8/y@kroah.com> (raw)
In-Reply-To: <DM6PR12MB425003383BBF9FB949D48B0FFBD49@DM6PR12MB4250.namprd12.prod.outlook.com>

On Wed, Sep 08, 2021 at 03:33:51PM +0000, Yu, Lang wrote:
> >Please feel free to add better documentation for the functions if you feel people
> >are getting confused, do not change the existing behavior of the code as it rightly
> >caught it being misused.
> 
> You can find many patches named "convert sysfs scnprintf/snprintf to syfs_emit/sysfs_emit_at".
> or "use sysfs_emit/sysfs_emit_at in show functions". They may think it's better to use syfs_emit/sysfs_emit_at
> given its overrun avoidance.

Yes, and using that in sysfs functions is fine, there is nothing wrong
with this usage.

> But there are still some corner cases(e.g., a non page boundary aligned buf address : ).

I need a specific example of where this has gone wrong.  Please provide
a lore.kernel.org link as I fail to see the problem here.

Are you sure that you are not just abusing sysfs and having more than
one value per file?  Does this mean I need to go audit all of the gpu
sysfs file entries?

thanks,

greg k-h

  reply	other threads:[~2021-09-09  5:19 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 [this message]
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
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=YTmZXU7myBFjx8/y@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Lang.Yu@amd.com \
    --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.