[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YzVXFOFeGkl33Yjv@octinomon>
Date: Thu, 29 Sep 2022 09:28:04 +0100
From: Jules Irenge <jbi.octave@...il.com>
To: David Sterba <dsterba@...e.cz>
Cc: peterz@...radead.org, Ingo Molnar <mingo@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [tip: perf/core] perf/core: Convert snprintf() to scnprintf()
On Wed, Sep 21, 2022 at 02:55:35PM +0200, David Sterba wrote:
> On Wed, Sep 21, 2022 at 12:44:35PM +0200, Ingo Molnar wrote:
> >
> > * Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > > On Wed, Sep 21, 2022 at 08:08:55AM -0000, tip-bot2 for Jules Irenge wrote:
> > > > The following commit has been merged into the perf/core branch of tip:
> > > >
> > > > Commit-ID: 678739d622ae7b75b62d550858b6bf104c43e2df
> > > > Gitweb: https://git.kernel.org/tip/678739d622ae7b75b62d550858b6bf104c43e2df
> > > > Author: Jules Irenge <jbi.octave@...il.com>
> > > > AuthorDate: Sun, 18 Sep 2022 00:41:08 +01:00
> > > > Committer: Ingo Molnar <mingo@...nel.org>
> > > > CommitterDate: Wed, 21 Sep 2022 10:01:20 +02:00
> > > >
> > > > perf/core: Convert snprintf() to scnprintf()
> > > >
> > > > Coccinelle reports a warning:
> > > >
> > > > WARNING: use scnprintf or sprintf
> > > >
> > > > Adding to that, there has also been some slow migration from snprintf to scnprintf.
> > > >
> > > > This LWN article explains the rationale for this change:
> > > >
> > > > https: //lwn.net/Articles/69419/
> > > >
> > > > No change in behavior.
> > > >
> > > > [ mingo: Improved the changelog. ]
> > >
> > > And yet, at this point I still have no clue what's wrong with
> > > snprintf(). So not much improvement :/
> >
> > I've added this to the changelog:
> >
> > perf/core: Convert snprintf() to scnprintf()
>
> I'm not sure if it would apply in this case as it's for a device
> attribute, but there's another helper sysfs_emit that does the safe
> print to string and one does not have to care which flavor of s*printf
> it is. We had patches in btrfs converting from snprintf to scnprintf and
> the latest one is sysfs_emit which is convenient to use but assumes the
> PAGE_SIZE of the buffer.
Yes, you are right. I can resend the patch with sysfs_emit() if
possible as the latest documentation on sysfs states that
show() device function should only use sysfs_emit() or sysfs_emit_at()
when formatting the value to be returned to user space.
* https://www.kernel.org/doc/html/latest/filesystems/sysfs.html
I don't know whether it may apply to this subsystem. I have to read
more about it and test
thanks
jules
Powered by blists - more mailing lists