[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201102144025.GL27442@casper.infradead.org>
Date: Mon, 2 Nov 2020 14:40:25 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Joe Perches <joe@...ches.com>, Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] mm: shmem: Convert shmem_enabled_show to use
sysfs_emit_at
On Mon, Nov 02, 2020 at 03:32:59PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Nov 02, 2020 at 02:08:36PM +0000, Matthew Wilcox wrote:
> > On Mon, Nov 02, 2020 at 02:33:43PM +0100, Greg Kroah-Hartman wrote:
> > > > Oh, ugh, sysfs_emit() should be able to work on a buffer that isn't
> > > > page aligned. Greg, how about this?
> > >
> > > How can sysfs_emit() be called on a non-page-aligned buffer? It's being
> > > used on the buffer that was passed to the sysfs call.
> > >
> > > And if you are writing multiple values to a single sysfs file output,
> > > well, not good...
> >
> > See shmem_enabled_show() in mm/shmem.c (output at
> > /sys/kernel/mm/transparent_hugepage/shmem_enabled on your machine).
> >
> > I don't claim it's a good interface, but it exists.
>
> Ok, that's a common pattern for sysfs files, not that bad.
>
> What's wrong with using sysfs_emit_at()? We want sysfs_emit() to "know"
> that the buffer is PAGE_SIZE big, if you try to allow offsets in it,
> that defeats the purpose of the check.
For someone who's used to C "strings", it's pretty common to do
something like:
buf += sprintf(buf, "foo ");
buf += sprintf(buf, "bar ");
sysfs_emit_at instead wants me to do:
len += sprintf(buf + len, "foo ");
len += sprintf(buf + len, "bar ");
I don't see how the code I wrote defeats the check. It checks that the
buffer never crosses a PAGE_SIZE boundary, which is equivalently safe.
Powered by blists - more mailing lists