public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Marek Behun <marek.behun@nic.cz>
Cc: Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org, Pavel Machek <pavel@ucw.cz>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>
Subject: Re: kernfs: can read/write method grow buffer size?
Date: Fri, 29 Mar 2019 07:22:53 +0100	[thread overview]
Message-ID: <20190329062253.GA9659@kroah.com> (raw)
In-Reply-To: <20190329040922.34ab01c6@nic.cz>

On Fri, Mar 29, 2019 at 04:09:22AM +0100, Marek Behun wrote:
> Hello Tejun and Greg,
> 
> kernfs_fop_open/read/write allocates a buffer for the ->read, ->write,
> or ->seq_read methods. This buffer is either preallocated or allocated
> on the spot, with minimum size being PAGE_SIZE, if ->atomic_write_len
> is not given.
> 
> There is a question/problem currently in the led-trigger API, that the
> PAGE_SIZE buffer can in some specific scenarios be too short.

And that file is in sysfs?  That's a huge abuse of the sysfs api then :(

> (The trigger file on read returns space separated list of all supported
> triggers, and the currently chosen one is marked specially. The cpu
> activity trigger lists "cpu%i" for all CPU cores, which actually broke
> on some machines with very large number of CPUs. Granted, this could
> have been solved another way (and maybe will be), but we are now
> discussing API for HW LED triggers, which can raise the problem anyway,
> if a specific LED controller supports too many HW LED triggers.)
> 
> Is it allowed to grow this buffer if needed, either via krealloc or by
> creating a special function in kernfs API which does this so that
> led-trigger could use it?
> 
> Or is this completely forbidden?

If this is just for kernfs, and you have your own filesystem, sure, we
can probably do something here.  But if this is for sysfs, no, you all
need to keep to the "one value per file" rule that we have there please.

thanks,

greg k-h

  reply	other threads:[~2019-03-29  6:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-29  3:09 kernfs: can read/write method grow buffer size? Marek Behun
2019-03-29  6:22 ` Greg Kroah-Hartman [this message]
2019-03-29  6:51   ` Marek Behun
2019-03-29  6:58     ` Greg Kroah-Hartman
2019-03-29  8:34   ` Pavel Machek
2019-03-29  8:48     ` Marek Behun
2019-03-29 10:24       ` Greg Kroah-Hartman
2019-03-29 10:26         ` Greg Kroah-Hartman
2019-03-29 10:38           ` Pavel Machek
2019-03-29 10:32         ` Pavel Machek

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=20190329062253.GA9659@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marek.behun@nic.cz \
    --cc=pavel@ucw.cz \
    --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