[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150822100333.GA23288@gmail.com>
Date: Sat, 22 Aug 2015 12:03:33 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Denys Vlasenko <dvlasenk@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
David Drysdale <drysdale@...gle.com>,
Andy Lutomirski <luto@...capital.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Will Drewry <wad@...omium.org>,
Alok Kataria <akataria@...are.com>,
Borislav Petkov <bp@...en8.de>,
Alexei Starovoitov <ast@...mgrid.com>,
Frederic Weisbecker <fweisbec@...il.com>,
"H. Peter Anvin" <hpa@...or.com>, Oleg Nesterov <oleg@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>, X86 ML <x86@...nel.org>
Subject: Re: [Regression v4.2 ?] 32-bit seccomp-BPF returned errno values
wrong in VM?
* Denys Vlasenko <dvlasenk@...hat.com> wrote:
> It was nearly inevitable that something would break during untangling.
1)
So the 'chronic lack of compat, audit/noaudit and Wine testing' was certainly
avoidable.
The problem wasn't the fact that something was bound to break, but the latency of
finding these bugs. If we cannot reduce the latency so that bugs are caught early
enough (before they reach mainline) then we shouldn't be doing such changes.
We are slowly adding tests for that in the x86 self-tests, but IMHO we should be
more proactive than that.
2)
Another structural problem I saw occasionally was the attempt to characterise away
regressions.
That's a 100% no-no: if a change breaks any user-space program, it does not matter
how 'correct' a change is, how weird the user-space dependence and how rare the
user-space program: the regression needs to be fixed either by going forward with
a fix or by going backwards via reverting the change.
Thanks,
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/
Powered by blists - more mailing lists