linux-kernel - Re: [PATCH RESEND] Update kernel math-emu code from current glibc soft-fp

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] [day] [month] [year] [list]

Date:	Thu, 02 Jul 2015 22:50:07 +1000
From:	Michael Ellerman <mpe@...erman.id.au>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Joseph Myers <joseph@...esourcery.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	alpha <linux-alpha@...r.kernel.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	linux-s390 <linux-s390@...r.kernel.org>,
	Linux-sh list <linux-sh@...r.kernel.org>,
	sparclinux <sparclinux@...r.kernel.org>,
	"David S.Miller" <davem@...emloft.net>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH RESEND] Update kernel math-emu code from current glibc
 soft-fp

On Wed, 2015-07-01 at 09:34 +0200, Geert Uytterhoeven wrote:
> On Wed, Jul 1, 2015 at 12:18 AM, Michael Ellerman <mpe@...erman.id.au> wrote:
> > On Tue, 2015-06-30 at 10:48 +0000, Joseph Myers wrote:
> >> On Tue, 30 Jun 2015, Michael Ellerman wrote:
> >>
> >> > Is there some way you can imagine of splitting this up into smaller chunks, so
> >> > that different arches can merge the pieces separately?
> >>
> >> Well, it could be split as:
> >>
> >> 1. Rename include/math-emu to math-emu-old and update architectures for
> >> the renaming (mechanically).
> >>
> >> 2. Add new include/math-emu.
> >>
> >> 3,4,5,6,7. Move each architecture from math-emu-old to math-emu.
> >>
> >> 8. Remove math-emu-old.
> >>
> >> You still have patch 1 affecting all five architectures, but with the
> >> per-architecture changes being much simpler.
> >
> > OK. That's obviously a bit more churn, but I think it's probably the best
> > approach. Unless someone else has a better idea?
> 
> Does it make that much of a difference?

Well yeah?

> You said:
> | However in it's current form it's not easily mergeable, because it
> touches five
> | architectures and has the potential to cause breakage on all of them.
> 
> Patch 1 still touches five architectures.

It does, but it would be mechanical, so in theory at least it should be a safe.

That patch could also go in a full release before the others, giving us the
maximum opportunity to test.

> Patches 3-7 still have the potential to break an architecture, but only one of
> them at a time.

Right. But each maintainer could take the patch for their arch and merge it as
they see fit.

The main advantage though would be if regressions are found we could revert
just the patch for a particular arch, rather than having to back out the whole
thing - which would be basically impossible.

> From a bisectability point of view there's no change.

Agreed.

The other problem if it's monolithic is who's tree does it go into? I guess
Andrews.

cheers



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