* [GIT PULL][PATCH] tracing: Fix buggered tee(2) on tracing_pipe
@ 2014-01-18 4:28 Steven Rostedt
0 siblings, 0 replies; only message in thread
From: Steven Rostedt @ 2014-01-18 4:28 UTC (permalink / raw)
To: Linus Torvalds, LKML; +Cc: Al Viro, Andrew Morton, Ingo Molnar
Linus,
Al Viro has concerns with the trace_pipe release method calling
__free_page() instead of using the generic_pipe_buf_release() which
does a page_cache_release(). Looking at the differences between
__free_page() and page_cache_release() I do not think there's a real
issue here. But to be on the safe side, and at least to be symmetric
with generic_pipe_buf_get(), this patch is fine to add.
Please pull the latest trace-fixes-v3.13-rc8 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-fixes-v3.13-rc8
Tag SHA1: 5a8329936de8662773042fa76bc3c3d0c48fe5c3
Head SHA1: c50b3d58415b1f46bdb044fbd4e807cda49f0aa2
Al Viro (1):
tracing: Fix buggered tee(2) on tracing_pipe
----
kernel/trace/trace.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
---------------------------
commit c50b3d58415b1f46bdb044fbd4e807cda49f0aa2
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date: Fri Jan 17 07:53:39 2014 -0500
tracing: Fix buggered tee(2) on tracing_pipe
In kernel/trace/trace.c we have this:
static void tracing_pipe_buf_release(struct pipe_inode_info *pipe,
struct pipe_buffer *buf)
{
__free_page(buf->page);
}
static const struct pipe_buf_operations tracing_pipe_buf_ops = {
.can_merge = 0,
.map = generic_pipe_buf_map,
.unmap = generic_pipe_buf_unmap,
.confirm = generic_pipe_buf_confirm,
.release = tracing_pipe_buf_release,
.steal = generic_pipe_buf_steal,
.get = generic_pipe_buf_get,
};
with
void generic_pipe_buf_get(struct pipe_inode_info *pipe, struct pipe_buffer *buf)
{
page_cache_get(buf->page);
}
and I don't see anything that would've prevented tee(2) called on the pipe
that got stuff spliced into it from that sucker. ->ops->get() will be
called, then buf gets copied into target pipe's ->bufs[] and eventually
readers get to both copies of the buffer. With
get_page(page)
look at that page
__free_page(page)
look at that page
__free_page(page)
which is not a good thing, to put it mildly. AFAICS, that ought to use
the normal generic_pipe_buf_release() (aka page_cache_release(buf->page)),
shouldn't it?
[
SDR - As trace_pipe just allocates the page with alloc_page(GFP_KERNEL),
and doesn't do anything special with it (no LRU logic). The __free_page()
should be fine, as it wont actually free a page with reference count.
Maybe there's a chance to leak memory? Anyway, This change is at a minimum
good for being symmetric with generic_pipe_buf_get, it is fine to add.
]
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[ SDR - Removed no longer used tracing_pipe_buf_release ]
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 9d20cd9..8f86143 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4212,12 +4212,6 @@ out:
return sret;
}
-static void tracing_pipe_buf_release(struct pipe_inode_info *pipe,
- struct pipe_buffer *buf)
-{
- __free_page(buf->page);
-}
-
static void tracing_spd_release_pipe(struct splice_pipe_desc *spd,
unsigned int idx)
{
@@ -4229,7 +4223,7 @@ static const struct pipe_buf_operations tracing_pipe_buf_ops = {
.map = generic_pipe_buf_map,
.unmap = generic_pipe_buf_unmap,
.confirm = generic_pipe_buf_confirm,
- .release = tracing_pipe_buf_release,
+ .release = generic_pipe_buf_release,
.steal = generic_pipe_buf_steal,
.get = generic_pipe_buf_get,
};
^ permalink raw reply related [flat|nested] only message in thread
only message in thread, other threads:[~2014-01-18 4:28 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-18 4:28 [GIT PULL][PATCH] tracing: Fix buggered tee(2) on tracing_pipe Steven Rostedt
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).