From: Tal Shorer <tal.shorer@gmail.com>
To: "<linux-kernel@vger.kernel.org>" <linux-kernel@vger.kernel.org>,
Joel Becker <jlbec@evilplan.org>,
hch@lst.de
Subject: Possible unwanted behaviour in configfs
Date: Sat, 25 Jun 2016 12:43:34 +0300 [thread overview]
Message-ID: <CAFDyS3MwuarsJVnR8E1OQjCF1vN4jZSs84zq-8sMysaOkQyS1g@mail.gmail.com> (raw)
Hey,
I encountered a possible unwanted behaviour in the way configfs
handles read() on items' attributes.
The show() function is called only once (which is good) on the first
time the user attempts to read from the file. If show() returns an
error that error is returned to the user. However, if the user calls
read() again, no data is copied (good) and a value of zero is
returned.
This is especially evident when using busybox's cat utility, which
first attempts sendfile64() and if that fails falls back to read(),
giving the user the impression that reading the attribute was
successful but no data was returned.
I traced this to the function configfs_read_file in fs/configfs/file.c
and have two fixes in mind:
1. In fill_read_buffer(), If an error is returned by show(), don't set
buffer->needs_read_fill to zero, making the next read() call show()
again and either get an error or data.
2. Add an "err" field to struct configfs_buffer and keep the returned
error from show() there. Any additional read() on this file will
return this error.
Any thoughts?
next reply other threads:[~2016-06-25 9:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-25 9:43 Tal Shorer [this message]
2016-06-30 9:32 ` Possible unwanted behaviour in configfs Christoph Hellwig
2016-07-01 9:28 ` [PATCH] fs: configfs: don't set buffer_needs_fill to zero if show() returns error Tal Shorer
2016-07-26 18:23 ` Tal Shorer
2016-07-27 11:30 ` Christoph Hellwig
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=CAFDyS3MwuarsJVnR8E1OQjCF1vN4jZSs84zq-8sMysaOkQyS1g@mail.gmail.com \
--to=tal.shorer@gmail.com \
--cc=hch@lst.de \
--cc=jlbec@evilplan.org \
--cc=linux-kernel@vger.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;
as well as URLs for NNTP newsgroup(s).