From: Al Viro <viro@ZenIV.linux.org.uk>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: keescook@chromium.org, joe@perches.com, linux@horizon.com,
akpm@linux-foundation.org, dan.carpenter@oracle.com,
davem@davemloft.net, eldad@fogrefinery.com, jbeulich@suse.com,
jkosina@suse.cz, linux-kernel@vger.kernel.org,
rdunlap@infradead.org
Subject: Re: [PATCH] vsprintf: drop comment claiming %n is ignored
Date: Sat, 14 Sep 2013 05:53:14 +0100 [thread overview]
Message-ID: <20130914045313.GB13318@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20130914034801.GA13318@ZenIV.linux.org.uk>
On Sat, Sep 14, 2013 at 04:48:02AM +0100, Al Viro wrote:
> Overall: I suspect that Joe might be right. The very few callers that
> use the return value and use it correctly can bloody well call
> seq_overflow(), preferably with a detailed comment about the reasons
> for doing so. Anything that really wants the length of output (if we
> have such places at all) can use %n or see Figure 1. I haven't
> crawled through lib/*, net/* and sound/* yet, but that's how the things
> look so far.
The same goes for seq_puts, seq_escape, seq_vprintf, seq_dentry,
seq_bitmap*, seq_cpumask*, seq_nodemask*, seq_putc, seq_put_decimal*
seq_puts() has one buggy user trying to return its return value from
->show(). seq_putc() has several such.
seq_path() returns length and in one case its return value is used
(right-padded pathname in /proc/swaps).
seq_path_root() returns what would be a valid return value for ->show()
(0 or 1, actually).
seq_write() return value is mostly ignored; kernel/trace/* is using it
to check for overflows, but its reaction to said overflows is odd.
The bottom line: most of these guys could as well return void; we have
few overflow checks and those could be made explicit. As it is,
"return -1 on overflow" had been a mistake. Mea culpa.
next prev parent reply other threads:[~2013-09-14 4:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-11 19:30 [PATCH] vsprintf: drop comment claiming %n is ignored Kees Cook
2013-09-11 20:06 ` Joe Perches
2013-09-11 20:18 ` Kees Cook
2013-09-11 20:20 ` Joe Perches
2013-09-11 20:30 ` KOSAKI Motohiro
2013-09-11 20:28 ` Joe Perches
2013-09-13 19:53 ` George Spelvin
2013-09-13 22:27 ` Joe Perches
2013-09-13 23:03 ` Kees Cook
2013-09-13 23:23 ` Joe Perches
2013-09-16 2:53 ` George Spelvin
2013-09-14 2:17 ` Al Viro
2013-09-14 2:49 ` Tetsuo Handa
2013-09-14 3:05 ` Al Viro
2013-09-14 3:48 ` Al Viro
2013-09-14 4:53 ` Al Viro [this message]
2013-09-14 5:26 ` Joe Perches
2013-09-12 7:03 ` Jan Beulich
2013-09-12 7:31 ` Kees Cook
2013-09-12 7:51 ` Jan Beulich
2013-09-12 7:57 ` Dan Carpenter
2013-09-13 19:49 ` George Spelvin
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=20130914045313.GB13318@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=dan.carpenter@oracle.com \
--cc=davem@davemloft.net \
--cc=eldad@fogrefinery.com \
--cc=jbeulich@suse.com \
--cc=jkosina@suse.cz \
--cc=joe@perches.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=rdunlap@infradead.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.