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]
Message-ID: <alpine.DEB.2.20.1711151613250.1805@nanos>
Date:   Wed, 15 Nov 2017 16:22:34 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...e.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: linux-next: manual merge of the rseq tree with Linus' tree

On Wed, 15 Nov 2017, Mathieu Desnoyers wrote:
> ----- On Nov 15, 2017, at 9:48 AM, Stephen Rothwell sfr@...b.auug.org.au wrote:
> 
> > Hi Ingo,
> > 
> > On Wed, 15 Nov 2017 09:07:12 +0100 Ingo Molnar <mingo@...nel.org> wrote:
> >>
> >> There's absolutely no way such invasive x86 changes should be done outside the
> >> x86
> >> tree and be merged into linux-next.
> >> 
> >> linux-next should be for the regular maintenance flow, for changes pushed by
> >> maintainers and part of the regular maintenance process - not for
> >> work-in-progress
> >> features that may or may not be merged upstream in that form ...
> > 
> > Sure.  I was given the impression that Linus was going to be asked to
> > merge this tree during this merge window, so I assumed that it had been
> > seen by the appropriate people.  Most of these patches include you,
> > Linus and Andrew (among others) on their cc's and they seem to have
> > gone through several revisions.
> > 
> > I guess Mathieu has jumped the gun.
> 
> The membarrier core serializing command has been developed in the open
> since Aug. 27, 2017 [1]. That's one full development cycle. On Sept 28,
> 2017, I started CCing Ingo when I noticed I would have to add documentation
> to each architecture return-to-usermode paths [2]. I have never heard feedback
> from him until now.
> 
> I am open to remove the x86-specific membarrier core serializing patch from
> my tree and hand it to the x86 maintainers after the generic code makes it
> into Linus' tree, if this is seen as the appropriate way forward.

To be honest, I was looking at this stuff losely, but the continous flux of
it and the entanglement with the rseq series did not really help.

I have no idea why you are trying to force shove that rseq stuff into
4.15. It's not been complete before the merge window opened and it's still
not complete AFAICT.

That x86 membarrier thing is not yet clear if it is required at all, so why
is this so high priority?

Can we please handle this as any other feature which is not ready before
the merge window and postpone the rseq stuff for 4.16?

The core serialization thing might be a correctness issue and we can fix
that independently once we have gathered enough information from
Intel/AMD.

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ