From: Tejun Heo <tj@kernel.org>
To: NeilBrown <neilb@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernfs: use stack-buf for small writes.
Date: Tue, 23 Sep 2014 01:51:56 -0400 [thread overview]
Message-ID: <20140923055156.GC11740@mtj.dyndns.org> (raw)
In-Reply-To: <20140923154058.6a1c2449@notabene.brown>
On Tue, Sep 23, 2014 at 03:40:58PM +1000, NeilBrown wrote:
> > Oh, I meant the buffer seqfile read op writes to, so it depends on the
> > fact that the allocation is only on the first read? That seems
> > extremely brittle to me, especially for an issue which tends to be
> > difficult to reproduce.
>
> It is easy for user-space to ensure they read once before any critical time..
Sure, but it's a hard and subtle dependency on an extremely obscure
implementation detail.
> > I'd much rather keep things direct and make it explicitly allocate r/w
> > buffer(s) on open and disallow seq_file operations on such files.
>
> As far as I can tell, seq_read is used on all sysfs files that are
> readable except for 'binary' files. Are you suggesting all files that might
> need to be accessed without a kmalloc have to be binary files?
kernfs ->direct_read() callback doesn't go through seq_file. sysfs
can be extended to support that for regular files, I guess. Or just
make those special files binary?
> Having to identify those files which are important in advance seems the more
> "brittle" approach to me. I would much rather it "just worked"
I disagree. The files which shouldn't involve memory allocations must
be identified no matter what. They're *very* special. And the rules
that userland has to follow seem completely broken to me. "Small"
writes are okay, whatever that means, and "small" reads are okay too
as long as it isn't the first read. Ooh, BTW, if the second read ends
up expanding the initial buffer, it isn't okay - the initial boundary
is PAGE_SIZE and the buffer is expanded twice on each overflow. How
are these rules okay? This is borderline crazy. In addition, the
read path involves a lot more code this way. It ends up locking down
buffer policies of the whole seqfile implementation.
> Would you prefer a new per-attribute flag which directed sysfs to
> pre-allocate a full page, or a 'max_size' attribute which caused a buffer of
> that size to be allocated on open?
> The same size would be used to pre-allocate the seqfile buf (like
> single_open_size does) if reads were supported.
Yes but I really think we should avoid seqfile dependency.
Thanks.
--
tejun
next prev parent reply other threads:[~2014-09-23 5:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-23 4:06 [PATCH] kernfs: use stack-buf for small writes NeilBrown
2014-09-23 4:12 ` Tejun Heo
2014-09-23 4:18 ` Tejun Heo
2014-09-23 4:46 ` NeilBrown
2014-09-23 4:55 ` Tejun Heo
2014-09-23 5:40 ` NeilBrown
2014-09-23 5:51 ` Tejun Heo [this message]
2014-09-23 6:11 ` NeilBrown
2014-09-23 6:15 ` Tejun Heo
2014-09-24 19:17 ` Al Viro
2014-09-24 23:58 ` NeilBrown
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=20140923055156.GC11740@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
/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