linux-kernel - Re: [PATCH 2/4] x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET

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:	Sat, 10 Jan 2015 14:27:06 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	X86 ML <x86@...nel.org>, Alexei Starovoitov <ast@...mgrid.com>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 2/4] x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET

On Sat, Jan 10, 2015 at 2:13 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> I'll make the same change to my pending entry work, and hopefully we
> can avoid conflicts.

That's not how conflicts work.

Either there is no overlap between the changes at all, in which case
it doesn't matter if you then also have Denys' changes in your tree.

Or you have other changes that change code around Denys' code, in
which case you'll get conflicts whether you have Denys' changes or not
(because two branches will be changing the same area differently, and
so there's a conflict that needs to resolve which side was right).

So the only way to avoid a conflict is to not touch the same code, or
to touch it *exactly* the same way in all respects.

Now, while the *conflict* is not something you can't avoid, some
conflicts are easier to resolve than others, and from a conflict
resolution standpoint it can make sense for your branch to include
Denys' changes.

Why? Because if whoever resolves the conflict sees that one branch is
a proper superset of the other branch, than the resolution is a much
more obvious "let's just take everything from one side" edit, rather
than having to pick-and-choose.

I I do actually agree with you taking the fixes (and maybe you should
*entirely* take ownership of all the entry_64.S changes, so that there
is no "other side" to conflict with at all!). I just wanted to point
out the actual effects from a conflict standpoint.

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