linux-kernel - Re: [GIT PULL] tracing: final fixes for events and some

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:	Mon, 05 Aug 2013 10:52:09 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: [GIT PULL] tracing: final fixes for events and some

On Mon, 2013-08-05 at 16:32 +0200, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > Linus,
> > 
> > Oleg Nesterov has been working hard in closing all the holes that can 
> > lead to race conditions between deleting an event and accessing an event 
> > debugfs file. This included a fix to the debugfs system (acked by Greg 
> > Kroah-Hartman). We think that all the holes have been patched and 
> > hopefully we don't find more. I haven't marked all of them for stable 
> > because I need to examine them more to figure out how far back some of 
> > the changes need to go.
> 
> Sigh, that's quite some churn still - unless these bugs were introduced in 
> the v3.11 merge window (i.e. are genuine _regressions_), shouldn't such 
> invasive fixes really go into v3.12 instead?

Some of these changes I could have pushed out in an earlier -rc, but we
were still discussing exactly how to fix these races, and I wanted the
right fix not the quickest fix. Not to mention, I wanted to heavily test
a lot of these changes which meant taking time to do so. We have a good
idea what the problem was, we wanted the best fix for the issue.

Now are these regressions? For 3.11, probably not. I think some of these
bugs can cause crashes back to at least 3.4, perhaps even 3.0. If I can
crash 3.0 which means it's not a regression, does that mean I should
wait for 3.12 and then push everything to stable? Is that what we
decided to do in that "when to use stable tag" discussion we had?

> 
> I see that some of the fixes here fix issues that your earlier post-rc1 
> rounds of non-regression fixes introduced to begin with. That's really not 
> a good pattern either IMO.

Not really. The earlier fixes closed some of the holes but were not good
enough. They didn't cause more regressions, but the method use to fix
the regressions it was trying to solve wasn't going to work when we saw
the extent of the regressions that had to be fixed. Oleg came up with a
better method, which meant that we had to undo the original fix, for a
even better fix.

-- Steve

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