Re: [Regression v4.2 ?] 32-bit seccomp-BPF returned errno values wrong in VM?

From: Ingo Molnar <mingo@kernel.org>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Kees Cook <keescook@chromium.org>,
	David Drysdale <drysdale@google.com>,
	Andy Lutomirski <luto@amacapital.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Will Drewry <wad@chromium.org>,
	Alok Kataria <akataria@vmware.com>,
	Borislav Petkov <bp@alien8.de>,
	Alexei Starovoitov <ast@plumgrid.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Oleg Nesterov <oleg@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>, X86 ML <x86@kernel.org>
Subject: Re: [Regression v4.2 ?] 32-bit seccomp-BPF returned errno values wrong in VM?
Date: Sat, 22 Aug 2015 12:03:33 +0200	[thread overview]
Message-ID: <20150822100333.GA23288@gmail.com> (raw)
In-Reply-To: <55CDCEF4.1090906@redhat.com>

* Denys Vlasenko <dvlasenk@redhat.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