public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH 0/2] splice patches for ftrace
@ 2009-02-09  6:15 Eduard - Gabriel Munteanu
  2009-02-09  6:15 ` [RFC PATCH 1/2] trace: Move pipe waiting code out of tracing_read_pipe() Eduard - Gabriel Munteanu
                   ` (3 more replies)
  0 siblings, 4 replies; 10+ messages in thread
From: Eduard - Gabriel Munteanu @ 2009-02-09  6:15 UTC (permalink / raw)
  To: mingo; +Cc: fweisbec, penberg, rostedt, Eduard - Gabriel Munteanu,
	linux-kernel

Hi,

This implements splice support so we can use it in kmemtrace-user. Please
check it out and tell me what you think.

The "RFC" in the subject reads like "I tested this the best I could,
although kmemtrace-user isn't still ready.". As we speak, I'm working on
making kmemtrace over ftrace and kmemtrace-user work together nicely.


	Cheers,
	Eduard

Eduard - Gabriel Munteanu (2):
  trace: Move pipe waiting code out of tracing_read_pipe().
  trace: splice support for tracing_pipe

 kernel/trace/trace.c |  205 +++++++++++++++++++++++++++++++++++++++++++-------
 kernel/trace/trace.h |    6 ++
 2 files changed, 182 insertions(+), 29 deletions(-)


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [RFC PATCH 1/2] trace: Move pipe waiting code out of tracing_read_pipe().
  2009-02-09  6:15 [RFC PATCH 0/2] splice patches for ftrace Eduard - Gabriel Munteanu
@ 2009-02-09  6:15 ` Eduard - Gabriel Munteanu
  2009-02-09  6:15 ` [RFC PATCH 2/2] trace: splice support for tracing_pipe Eduard - Gabriel Munteanu
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 10+ messages in thread
From: Eduard - Gabriel Munteanu @ 2009-02-09  6:15 UTC (permalink / raw)
  To: mingo; +Cc: fweisbec, penberg, rostedt, Eduard - Gabriel Munteanu,
	linux-kernel

This moves the pipe waiting code from tracing_read_pipe() into
tracing_wait_pipe(), which is useful to implement other fops, like
splice_read.

Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
---
 kernel/trace/trace.c |   69 +++++++++++++++++++++++++++++---------------------
 1 files changed, 40 insertions(+), 29 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index ef4dbac..130c4f5 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2359,37 +2359,15 @@ tracing_poll_pipe(struct file *filp, poll_table *poll_table)
 	}
 }
 
-/*
- * Consumer reader.
- */
-static ssize_t
-tracing_read_pipe(struct file *filp, char __user *ubuf,
-		  size_t cnt, loff_t *ppos)
+/* Must be called with trace_types_lock mutex held. */
+static int tracing_wait_pipe(struct file *filp)
 {
 	struct trace_iterator *iter = filp->private_data;
-	ssize_t sret;
-
-	/* return any leftover data */
-	sret = trace_seq_to_user(&iter->seq, ubuf, cnt);
-	if (sret != -EBUSY)
-		return sret;
-
-	trace_seq_reset(&iter->seq);
 
-	mutex_lock(&trace_types_lock);
-	if (iter->trace->read) {
-		sret = iter->trace->read(iter, filp, ubuf, cnt, ppos);
-		if (sret)
-			goto out;
-	}
-
-waitagain:
-	sret = 0;
 	while (trace_empty(iter)) {
 
 		if ((filp->f_flags & O_NONBLOCK)) {
-			sret = -EAGAIN;
-			goto out;
+			return -EAGAIN;
 		}
 
 		/*
@@ -2414,12 +2392,11 @@ waitagain:
 		iter->tr->waiter = NULL;
 
 		if (signal_pending(current)) {
-			sret = -EINTR;
-			goto out;
+			return -EINTR;
 		}
 
 		if (iter->trace != current_trace)
-			goto out;
+			return 0;
 
 		/*
 		 * We block until we read something and tracing is disabled.
@@ -2436,9 +2413,43 @@ waitagain:
 		continue;
 	}
 
+	return 1;
+}
+
+/*
+ * Consumer reader.
+ */
+static ssize_t
+tracing_read_pipe(struct file *filp, char __user *ubuf,
+		  size_t cnt, loff_t *ppos)
+{
+	struct trace_iterator *iter = filp->private_data;
+	ssize_t sret;
+
+	/* return any leftover data */
+	sret = trace_seq_to_user(&iter->seq, ubuf, cnt);
+	if (sret != -EBUSY)
+		return sret;
+
+	trace_seq_reset(&iter->seq);
+
+	mutex_lock(&trace_types_lock);
+	if (iter->trace->read) {
+		sret = iter->trace->read(iter, filp, ubuf, cnt, ppos);
+		if (sret)
+			goto out;
+	}
+
+waitagain:
+	sret = tracing_wait_pipe(filp);
+	if (sret <= 0)
+		goto out;
+
 	/* stop when tracing is finished */
-	if (trace_empty(iter))
+	if (trace_empty(iter)) {
+		sret = 0;
 		goto out;
+	}
 
 	if (cnt >= PAGE_SIZE)
 		cnt = PAGE_SIZE - 1;
-- 
1.6.0.6


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [RFC PATCH 2/2] trace: splice support for tracing_pipe
  2009-02-09  6:15 [RFC PATCH 0/2] splice patches for ftrace Eduard - Gabriel Munteanu
  2009-02-09  6:15 ` [RFC PATCH 1/2] trace: Move pipe waiting code out of tracing_read_pipe() Eduard - Gabriel Munteanu
@ 2009-02-09  6:15 ` Eduard - Gabriel Munteanu
  2009-02-09  9:04   ` Ingo Molnar
  2009-02-09 15:49   ` Steven Rostedt
  2009-02-09 14:10 ` [RFC PATCH 0/2] splice patches for ftrace Steven Rostedt
  2009-02-09 14:43 ` Pekka Enberg
  3 siblings, 2 replies; 10+ messages in thread
From: Eduard - Gabriel Munteanu @ 2009-02-09  6:15 UTC (permalink / raw)
  To: mingo; +Cc: fweisbec, penberg, rostedt, Eduard - Gabriel Munteanu,
	linux-kernel

Added and implemented tracing_pipe_fops->splice_read(). This allows
userspace programs to get tracing data more efficiently.

Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
---
 kernel/trace/trace.c |  136 ++++++++++++++++++++++++++++++++++++++++++++++++++
 kernel/trace/trace.h |    6 ++
 2 files changed, 142 insertions(+), 0 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 130c4f5..5b136ed 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -31,6 +31,7 @@
 #include <linux/fs.h>
 #include <linux/kprobes.h>
 #include <linux/writeback.h>
+#include <linux/splice.h>
 
 #include <linux/stacktrace.h>
 #include <linux/ring_buffer.h>
@@ -364,6 +365,25 @@ ssize_t trace_seq_to_user(struct trace_seq *s, char __user *ubuf, size_t cnt)
 	return cnt;
 }
 
+ssize_t trace_seq_to_buffer(struct trace_seq *s, void *buf, size_t cnt)
+{
+	int len;
+	void *ret;
+
+	if (s->len <= s->readpos)
+		return -EBUSY;
+
+	len = s->len - s->readpos;
+	if (cnt > len)
+		cnt = len;
+	ret = memcpy(buf, s->buffer + s->readpos, cnt);
+	if (!ret)
+		return -EFAULT;
+
+	s->readpos += len;
+	return cnt;
+}
+
 static void
 trace_print_seq(struct seq_file *m, struct trace_seq *s)
 {
@@ -2495,6 +2515,121 @@ 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)
+{
+	__free_page(spd->pages[idx]);
+}
+
+static 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,
+};
+
+static ssize_t tracing_splice_read_pipe(struct file *filp,
+					loff_t *ppos,
+					struct pipe_inode_info *pipe,
+					size_t len,
+					unsigned int flags)
+{
+	struct page *pages[PIPE_BUFFERS];
+	struct partial_page partial[PIPE_BUFFERS];
+	struct trace_iterator *iter = filp->private_data;
+	struct splice_pipe_desc spd = {
+		.pages = pages,
+		.partial = partial,
+		.nr_pages = 0, /* This gets updated below. */
+		.flags = flags,
+		.ops = &tracing_pipe_buf_ops,
+		.spd_release = tracing_spd_release_pipe,
+	};
+	ssize_t ret;
+	size_t count, rem;
+	unsigned int i;
+
+	mutex_lock(&trace_types_lock);
+
+	if (iter->trace->splice_read) {
+		ret = iter->trace->splice_read(iter, filp,
+					       ppos, pipe, len, flags);
+		if (ret)
+			goto out;
+	}
+
+	ret = tracing_wait_pipe(filp);
+	if (ret <= 0)
+		goto out;
+
+	if (!iter->ent && !find_next_entry_inc(iter)) {
+		ret = -EFAULT;
+		goto out;
+	}
+
+	/* Fill as many pages as possible. */
+	for (i = 0, rem = len; i < PIPE_BUFFERS && rem; i++) {
+		pages[i] = alloc_page(GFP_KERNEL);
+
+		/* Seq buffer is page-sized, exactly what we need. */
+		for (;;) {
+			count = iter->seq.len;
+			ret = print_trace_line(iter);
+			count = iter->seq.len - count;
+			if (rem < count) {
+				rem = 0;
+				iter->seq.len -= count;
+				break;
+			}
+			if (ret == TRACE_TYPE_PARTIAL_LINE) {
+				iter->seq.len -= count;
+				break;
+			}
+
+			trace_consume(iter);
+			rem -= count;
+			if (!find_next_entry_inc(iter))	{
+				rem = 0;
+				iter->ent = NULL;
+				break;
+			}
+		}
+
+		/* Copy the data into the page, so we can start over. */
+		ret = trace_seq_to_buffer(&iter->seq,
+					  page_address(pages[i]),
+					  iter->seq.len);
+		if (ret < 0) {
+			__free_page(pages[i]);
+			break;
+		}
+		partial[i].offset = 0;
+		partial[i].len = iter->seq.len;
+
+		trace_seq_reset(&iter->seq);
+	}
+
+	mutex_unlock(&trace_types_lock);
+
+	spd.nr_pages = i;
+
+	return splice_to_pipe(pipe, &spd);
+
+out:
+	mutex_unlock(&trace_types_lock);
+
+	return ret;
+}
+
 static ssize_t
 tracing_entries_read(struct file *filp, char __user *ubuf,
 		     size_t cnt, loff_t *ppos)
@@ -2658,6 +2793,7 @@ static struct file_operations tracing_pipe_fops = {
 	.open		= tracing_open_pipe,
 	.poll		= tracing_poll_pipe,
 	.read		= tracing_read_pipe,
+	.splice_read	= tracing_splice_read_pipe,
 	.release	= tracing_release_pipe,
 };
 
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index f2742fb..d58c305 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -352,6 +352,12 @@ struct tracer {
 	ssize_t			(*read)(struct trace_iterator *iter,
 					struct file *filp, char __user *ubuf,
 					size_t cnt, loff_t *ppos);
+	ssize_t			(*splice_read)(struct trace_iterator *iter,
+					       struct file *filp,
+					       loff_t *ppos,
+					       struct pipe_inode_info *pipe,
+					       size_t len,
+					       unsigned int flags);
 #ifdef CONFIG_FTRACE_STARTUP_TEST
 	int			(*selftest)(struct tracer *trace,
 					    struct trace_array *tr);
-- 
1.6.0.6


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [RFC PATCH 2/2] trace: splice support for tracing_pipe
  2009-02-09  6:15 ` [RFC PATCH 2/2] trace: splice support for tracing_pipe Eduard - Gabriel Munteanu
@ 2009-02-09  9:04   ` Ingo Molnar
  2009-02-09 15:49   ` Steven Rostedt
  1 sibling, 0 replies; 10+ messages in thread
From: Ingo Molnar @ 2009-02-09  9:04 UTC (permalink / raw)
  To: Eduard - Gabriel Munteanu; +Cc: fweisbec, penberg, rostedt, linux-kernel


* Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> wrote:

> Added and implemented tracing_pipe_fops->splice_read(). This allows
> userspace programs to get tracing data more efficiently.

Cool!

The structure of the splice state machine looks good - havent tested it yet.

A few comments:

> +static 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,
> +};

this looks nicer:

 static 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,
 };

(and this is how we do these things elsewhere in the tracing code)

ditto:

> +	struct splice_pipe_desc spd = {
> +		.pages = pages,
> +		.partial = partial,
> +		.nr_pages = 0, /* This gets updated below. */
> +		.flags = flags,
> +		.ops = &tracing_pipe_buf_ops,
> +		.spd_release = tracing_spd_release_pipe,
> +	};

+       for (i = 0, rem = len; i < PIPE_BUFFERS && rem; i++) {
+               pages[i] = alloc_page(GFP_KERNEL);
+
+               /* Seq buffer is page-sized, exactly what we need. */
+               for (;;) {

Ok, that's a minor bug: should check for NULL alloc_page() return.

> +out:
> +	mutex_unlock(&trace_types_lock);
> +
> +	return ret;

please name this label as 'out_err' - which it really is. We generally use the 
'out:' label for error-less exits.

Btw., this is how we do structure initializations:

>  	.open		= tracing_open_pipe,
>  	.poll		= tracing_poll_pipe,
>  	.read		= tracing_read_pipe,
> +	.splice_read	= tracing_splice_read_pipe,
>  	.release	= tracing_release_pipe,
>  };

One more thing, i'd suggest to split this loop (which is an iterator in a larger 
loop):

+               /* Seq buffer is page-sized, exactly what we need. */
+               for (;;) {
+                       count = iter->seq.len;
+                       ret = print_trace_line(iter);
[...]
+		}

Out into a separate helper inline function. This really is a "fill in pipe page" 
logic and having it separate makes it easier to review the splice-loop code pattern 
itself.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC PATCH 0/2] splice patches for ftrace
  2009-02-09  6:15 [RFC PATCH 0/2] splice patches for ftrace Eduard - Gabriel Munteanu
  2009-02-09  6:15 ` [RFC PATCH 1/2] trace: Move pipe waiting code out of tracing_read_pipe() Eduard - Gabriel Munteanu
  2009-02-09  6:15 ` [RFC PATCH 2/2] trace: splice support for tracing_pipe Eduard - Gabriel Munteanu
@ 2009-02-09 14:10 ` Steven Rostedt
  2009-02-09 14:17   ` Ingo Molnar
  2009-02-09 14:43 ` Pekka Enberg
  3 siblings, 1 reply; 10+ messages in thread
From: Steven Rostedt @ 2009-02-09 14:10 UTC (permalink / raw)
  To: Eduard - Gabriel Munteanu; +Cc: mingo, fweisbec, penberg, linux-kernel


On Mon, 9 Feb 2009, Eduard - Gabriel Munteanu wrote:

> Hi,
> 
> This implements splice support so we can use it in kmemtrace-user. Please
> check it out and tell me what you think.
> 
> The "RFC" in the subject reads like "I tested this the best I could,
> although kmemtrace-user isn't still ready.". As we speak, I'm working on
> making kmemtrace over ftrace and kmemtrace-user work together nicely.

Hi Eduard!

Thanks, I'll give it a test. I've been playing on my spare time with
a ring buffer splice interface. But I've not had the time to get it 
working fully. My version would be a binary only interface, but I really 
like the text interface you have.

You can look at my old changes at:

 git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git

  The branch tip/splice-broken

As the name suggests, it is still broken ;-)

-- Steve


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC PATCH 0/2] splice patches for ftrace
  2009-02-09 14:10 ` [RFC PATCH 0/2] splice patches for ftrace Steven Rostedt
@ 2009-02-09 14:17   ` Ingo Molnar
  0 siblings, 0 replies; 10+ messages in thread
From: Ingo Molnar @ 2009-02-09 14:17 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Eduard - Gabriel Munteanu, fweisbec, penberg, linux-kernel


* Steven Rostedt <rostedt@goodmis.org> wrote:

> 
> On Mon, 9 Feb 2009, Eduard - Gabriel Munteanu wrote:
> 
> > Hi,
> > 
> > This implements splice support so we can use it in kmemtrace-user. Please
> > check it out and tell me what you think.
> > 
> > The "RFC" in the subject reads like "I tested this the best I could,
> > although kmemtrace-user isn't still ready.". As we speak, I'm working on
> > making kmemtrace over ftrace and kmemtrace-user work together nicely.
> 
> Hi Eduard!
> 
> Thanks, I'll give it a test. I've been playing on my spare time with
> a ring buffer splice interface. But I've not had the time to get it 
> working fully. My version would be a binary only interface, but I really 
> like the text interface you have.
> 
> You can look at my old changes at:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> 
>   The branch tip/splice-broken
> 
> As the name suggests, it is still broken ;-)

I'd suggest we pick up Eduard's, with the fixes i suggested - because
they clearly work for his kmemtrace utility!

Then pick up whatever is left in your branch.

	Ingo

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC PATCH 0/2] splice patches for ftrace
  2009-02-09  6:15 [RFC PATCH 0/2] splice patches for ftrace Eduard - Gabriel Munteanu
                   ` (2 preceding siblings ...)
  2009-02-09 14:10 ` [RFC PATCH 0/2] splice patches for ftrace Steven Rostedt
@ 2009-02-09 14:43 ` Pekka Enberg
  3 siblings, 0 replies; 10+ messages in thread
From: Pekka Enberg @ 2009-02-09 14:43 UTC (permalink / raw)
  To: Eduard - Gabriel Munteanu; +Cc: mingo, fweisbec, rostedt, linux-kernel

On Mon, 2009-02-09 at 08:15 +0200, Eduard - Gabriel Munteanu wrote:
> This implements splice support so we can use it in kmemtrace-user. Please
> check it out and tell me what you think.

I am not a splice or ftrace expert but modulo the comments from Ingo:

Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC PATCH 2/2] trace: splice support for tracing_pipe
  2009-02-09  6:15 ` [RFC PATCH 2/2] trace: splice support for tracing_pipe Eduard - Gabriel Munteanu
  2009-02-09  9:04   ` Ingo Molnar
@ 2009-02-09 15:49   ` Steven Rostedt
  2009-02-11 12:35     ` Ingo Molnar
  1 sibling, 1 reply; 10+ messages in thread
From: Steven Rostedt @ 2009-02-09 15:49 UTC (permalink / raw)
  To: Eduard - Gabriel Munteanu; +Cc: mingo, fweisbec, penberg, linux-kernel


On Mon, 9 Feb 2009, Eduard - Gabriel Munteanu wrote:
> +
> +static ssize_t tracing_splice_read_pipe(struct file *filp,
> +					loff_t *ppos,
> +					struct pipe_inode_info *pipe,
> +					size_t len,
> +					unsigned int flags)
> +{
> +	struct page *pages[PIPE_BUFFERS];
> +	struct partial_page partial[PIPE_BUFFERS];
> +	struct trace_iterator *iter = filp->private_data;
> +	struct splice_pipe_desc spd = {
> +		.pages = pages,
> +		.partial = partial,
> +		.nr_pages = 0, /* This gets updated below. */
> +		.flags = flags,
> +		.ops = &tracing_pipe_buf_ops,
> +		.spd_release = tracing_spd_release_pipe,
> +	};

Note, this is getting a little stack heavy. It is still in bounds,
but I get very nervous when I see structure arrays on the stack.
If either the structure or the array grows large, we can be in trouble.

-- Steve


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC PATCH 2/2] trace: splice support for tracing_pipe
  2009-02-09 15:49   ` Steven Rostedt
@ 2009-02-11 12:35     ` Ingo Molnar
  2009-02-11 13:19       ` Frederic Weisbecker
  0 siblings, 1 reply; 10+ messages in thread
From: Ingo Molnar @ 2009-02-11 12:35 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Eduard - Gabriel Munteanu, fweisbec, penberg, linux-kernel


* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Mon, 9 Feb 2009, Eduard - Gabriel Munteanu wrote:
> > +
> > +static ssize_t tracing_splice_read_pipe(struct file *filp,
> > +					loff_t *ppos,
> > +					struct pipe_inode_info *pipe,
> > +					size_t len,
> > +					unsigned int flags)
> > +{
> > +	struct page *pages[PIPE_BUFFERS];
> > +	struct partial_page partial[PIPE_BUFFERS];
> > +	struct trace_iterator *iter = filp->private_data;
> > +	struct splice_pipe_desc spd = {
> > +		.pages = pages,
> > +		.partial = partial,
> > +		.nr_pages = 0, /* This gets updated below. */
> > +		.flags = flags,
> > +		.ops = &tracing_pipe_buf_ops,
> > +		.spd_release = tracing_spd_release_pipe,
> > +	};
> 
> Note, this is getting a little stack heavy. It is still in bounds,
> but I get very nervous when I see structure arrays on the stack.
> If either the structure or the array grows large, we can be in trouble.

Good point - but note that this is how splice support is implemented in
a number of other files - so if PIPE_BUFFERS or partial_page grows in
size, those places will fail too.

	Ingo

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC PATCH 2/2] trace: splice support for tracing_pipe
  2009-02-11 12:35     ` Ingo Molnar
@ 2009-02-11 13:19       ` Frederic Weisbecker
  0 siblings, 0 replies; 10+ messages in thread
From: Frederic Weisbecker @ 2009-02-11 13:19 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Steven Rostedt, Eduard - Gabriel Munteanu, penberg, linux-kernel

On Wed, Feb 11, 2009 at 01:35:26PM +0100, Ingo Molnar wrote:
> 
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > On Mon, 9 Feb 2009, Eduard - Gabriel Munteanu wrote:
> > > +
> > > +static ssize_t tracing_splice_read_pipe(struct file *filp,
> > > +					loff_t *ppos,
> > > +					struct pipe_inode_info *pipe,
> > > +					size_t len,
> > > +					unsigned int flags)
> > > +{
> > > +	struct page *pages[PIPE_BUFFERS];
> > > +	struct partial_page partial[PIPE_BUFFERS];
> > > +	struct trace_iterator *iter = filp->private_data;
> > > +	struct splice_pipe_desc spd = {
> > > +		.pages = pages,
> > > +		.partial = partial,
> > > +		.nr_pages = 0, /* This gets updated below. */
> > > +		.flags = flags,
> > > +		.ops = &tracing_pipe_buf_ops,
> > > +		.spd_release = tracing_spd_release_pipe,
> > > +	};
> > 
> > Note, this is getting a little stack heavy. It is still in bounds,
> > but I get very nervous when I see structure arrays on the stack.
> > If either the structure or the array grows large, we can be in trouble.
> 
> Good point - but note that this is how splice support is implemented in
> a number of other files - so if PIPE_BUFFERS or partial_page grows in
> size, those places will fail too.
> 
> 	Ingo

I first thought they can be declared as static, since the read_pipe functions
are not supposed to be reentrant, only one reader is allowed inside the pipe
(serialized with a global mutex).
But the mutex is released while waiting, and still, I guess it should be
reentrant one day if we plan to let the user having one trace_pipe per
cpu trace.

Would a dynamic allocation be too much overhead for that?


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2009-02-11 13:20 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-09  6:15 [RFC PATCH 0/2] splice patches for ftrace Eduard - Gabriel Munteanu
2009-02-09  6:15 ` [RFC PATCH 1/2] trace: Move pipe waiting code out of tracing_read_pipe() Eduard - Gabriel Munteanu
2009-02-09  6:15 ` [RFC PATCH 2/2] trace: splice support for tracing_pipe Eduard - Gabriel Munteanu
2009-02-09  9:04   ` Ingo Molnar
2009-02-09 15:49   ` Steven Rostedt
2009-02-11 12:35     ` Ingo Molnar
2009-02-11 13:19       ` Frederic Weisbecker
2009-02-09 14:10 ` [RFC PATCH 0/2] splice patches for ftrace Steven Rostedt
2009-02-09 14:17   ` Ingo Molnar
2009-02-09 14:43 ` Pekka Enberg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox