linux-ext4 - 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 07:40:51 -0400
From:	Theodore Tso <tytso@....edu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	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

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.)

> 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.

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?

	      		       	      - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html