Linux driver-core infrastructure
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox