All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>,
	fweisbec@gmail.com, penberg@cs.helsinki.fi,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] trace: splice support for tracing_pipe
Date: Wed, 11 Feb 2009 13:35:26 +0100	[thread overview]
Message-ID: <20090211123526.GF16535@elte.hu> (raw)
In-Reply-To: <alpine.DEB.1.10.0902091048310.14528@gandalf.stny.rr.com>


* 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

  reply	other threads:[~2009-02-11 12:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

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=20090211123526.GF16535@elte.hu \
    --to=mingo@elte.hu \
    --cc=eduard.munteanu@linux360.ro \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=rostedt@goodmis.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.