public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Theodore Tso <tytso@mit.edu>, Ingo Molnar <mingo@elte.hu>,
	Christoph Hellwig <hch@lst.de>,
	linux-kernel@vger.kernel.org,
	Fr?d?ric Weisbecker <fweisbec@gmail.com>,
	Steven Rostedt <rost
Subject: Re: [PATCH] ext4/jbd2: remove stray markers
Date: Wed, 6 May 2009 13:44:15 +0200	[thread overview]
Message-ID: <20090506114415.GA26947@lst.de> (raw)
In-Reply-To: <20090506114051.GA4964@mit.edu>

On Wed, May 06, 2009 at 07:40:51AM -0400, Theodore Tso wrote:
> My complaint with Cristoph's

Christoph, still :)

> is that it will conflict with patches I
> have pending which replaces the markers with tracepoints --- and I
> *am* using the tracepoints actively.  The only reason why these
> patches aren't in -stable is they have a dependency one of Rostedt's
> changes.  (Not a syntactic dependency, but if we merge in the wrong
> order, and the rcu_read_lock/unlock() calls aren't around the
> TP_PRINTK callpoint, then in certain CONFIG_PREEMPT configurations and
> if there is more than one active ext4 filesystem while the ext4 or
> jbd2 tracepoints are active, there's a potential race.)

Also without Steve's updates you can't actually use them in a module.

> My plan was to wait for the tracing patches to get pushed during the
> 2.6.31 merge tree, at which point I would then push my changes which
> replace the markers with TRACE_EVENT changes.  So no matter which way
> we do this, the ext4 markers will be gone by the end of the 2.6.31
> merge window.
> 
> Christoph, if you have some desire to completely remove the
> CONFIG_MARKERS support code, and I'm holding up your ability to do
> work, I can take the ext4 TRACE_EVENT patches, and queue them up in
> tip/tracing.  It's less work than if we take your markers removal
> patches, since then I would have to resolve all of the conflicts with
> my patches which replace all of the ext4 and jbd2 markers with
> TRACE_EVENTS macros.

I was planning to do make sure it's all gone.  Once we are into the
2.6.31 merge dinwo I fear that the final patches will miss the window
due to all these interdependencies.  But Ingo didn't seem to be too
interested in taking the other patches that would be required for it,
so I guess I'll try to somehow get it done in the merge window and
otherwise we'll have to wait for 2.6.32.


  reply	other threads:[~2009-05-06 11:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-06 10:44 [PATCH] ext4/jbd2: remove stray markers Christoph Hellwig
2009-05-06 11:03 ` Ingo Molnar
2009-05-06 11:07   ` Christoph Hellwig
2009-05-06 11:12     ` Ingo Molnar
2009-05-06 11:40   ` Theodore Tso
2009-05-06 11:44     ` Christoph Hellwig [this message]
2009-05-06 11:58       ` Ingo Molnar
2009-05-06 12:55       ` Theodore Tso
2009-05-06 13:18         ` Ingo Molnar
2009-05-06 11:54     ` Ingo Molnar

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=20090506114415.GA26947@lst.de \
    --to=hch@lst.de \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tytso@mit.edu \
    /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