linux-kernel - Re: [PATCH] ext4/jbd2: remove stray markers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 May 2009 13:54:21 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Theodore Tso <tytso@....edu>, Christoph Hellwig <hch@....de>,
	linux-kernel@...r.kernel.org,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4/jbd2: remove stray markers


* Theodore Tso <tytso@....edu> wrote:

> On Wed, May 06, 2009 at 01:03:54PM +0200, Ingo Molnar wrote:
> > 
> > > Ted, I think you have some TRAVE_EVENT patches for ext4 pending, 
> > > but is it okay to queue up this removal in the tracing tree?  That 
> > > way we can remove the markers leftovers there completely as soon 
> > > as the 2.6.31 merge window opens.
> > 
> > i think these markers are still in active use, so i'd not remove 
> > them before Ted's TRACE_EVENT() changes are included. We can/should 
> > do that in a single topic - in a work flow that suits Ted best.
> 
> My complaint with Cristoph's 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.)

That's OK.

> > We can do a -git based special-purpose topic branch in -tip, or 
> > we can do it in tip/tracing, or we can pull a (-git based) 
> > branch from Ted. Or we can delay it all to the v2.6.31 merge 
> > window. Ted's choice.
> 
> 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.

That's a perfectly fine approach.

> 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.
> 
> My preference is for the former, mainly because my patches are 
> already set up for that, and I'm a lazy bastard; the latter 
> wouldn't be much work, though.  I'm guessing your preference would 
> be for the latter?

No, lets delay this to the v2.6.31 merge window. I'd like to remove 
markers - but not at the cost of making life harder for others and 
at the cost of creating inter-dependencies on such a level.

I objected to markers back when they were merged in a rather 
haphazard way, but i'll object to any haphazard removal just as much 
;-) The .31 merge window will open in about a month.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/