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 15:27:24 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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:27 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> 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.

Hmm.  What I meant here about avoiding conflicts was more like "with
any luck, the timing will work out such that the code conflicts don't
end up happening."

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

Egads.  As if the vdso isn't bad enough.

Mumble mumble maybe I'll agree to maintain this masterpiece of
well-engineered asm.

--Andy

>                           Linus



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/