All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>, NeilBrown <neil@brown.name>,
	Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH] sysfs: clamp show() return value in sysfs_kf_read()
Date: Thu, 21 May 2026 10:17:16 +0100	[thread overview]
Message-ID: <20260521101716.6e460242@pumpkin> (raw)
In-Reply-To: <2026052148-glamorous-hassle-2cc8@gregkh>

On Thu, 21 May 2026 08:19:16 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Wed, May 20, 2026 at 11:11:58PM +0100, David Laight wrote:
> > On Wed, 20 May 2026 15:07:01 +0200
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >   
> > > sysfs_kf_seq_show() defends against buggy show() callbacks that return
> > > larger than PAGE_SIZE by clamping the value and printing a warning.
> > > sysfs_kf_read(), the prealloc variant, has no such defense.
> > > 
> > > The only current in-tree user of __ATTR_PREALLOC is drivers/md/md.c,
> > > whose show() callbacks are well-behaved, so this is hardening against
> > > future drivers doing foolish things and out-of-tree code doing even more
> > > foolish things.  
> > 
> > What is the rational for it using PREALLOC?  
> 
> No idea, you might want to dig to find the commit that did this.

This one:
commit 750f199ee8b578062341e6ddfe36c59ac8ff2dcb
Author: NeilBrown <neil@brown.name>
Date:   Tue Sep 30 08:53:05 2014 +1000

    md: mark some attributes as pre-alloc
    
    Since __ATTR_PREALLOC was introduced in v3.19-rc1~78^2~18
    it can now be used by md.
    
    This ensure that writing to these sysfs attributes will never
    block due to a memory allocation.
    Such blocking could become a deadlock if mdmon is trying to
    reconfigure an array after a failure prior to re-enabling writes.

That might be better handled with a flag that changes the kmalloc()
to NOIO and falls back onto a global preallocated page in the
normal path.
It would certainly let a lot of code be deleted (always good).

The atomic_write_len would then just be a max_write_len
(and maybe renamed).
The only real use is the 'cgroup' code that wants to support writes
that are larger than 4k.

Currently, if atomic_write_len is zero writes are truncated to PAGE_SIZE,
if non-zero overlong writes are rejected.

AFAICT the file offset is never checked - so all writes are (sort of) appends.
I'm not at all sure that makes sense.
Possibly all overlong writes should be rejected.

-- David

> 
> thanks,
> 
> greg k-h


      reply	other threads:[~2026-05-21  9:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20 13:07 [PATCH] sysfs: clamp show() return value in sysfs_kf_read() Greg Kroah-Hartman
2026-05-20 13:36 ` Rafael J. Wysocki
2026-05-20 14:43 ` Danilo Krummrich
2026-05-20 18:19 ` Tejun Heo
2026-05-21  6:18   ` Greg Kroah-Hartman
2026-05-21 10:04     ` David Laight
2026-05-21 16:18     ` Tejun Heo
2026-05-21 21:42       ` David Laight
2026-05-20 22:11 ` David Laight
2026-05-21  6:19   ` Greg Kroah-Hartman
2026-05-21  9:17     ` David Laight [this message]

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=20260521101716.6e460242@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=dakr@kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=rafael@kernel.org \
    --cc=tj@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.