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
| ||
|
Date: Wed, 29 Mar 2017 10:59:45 +0200 From: Ingo Molnar <mingo@...nel.org> To: Juergen Gross <jgross@...e.com> Cc: Stephen Rothwell <sfr@...b.auug.org.au>, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, Stefano Stabellini <sstabellini@...nel.org>, Boris Ostrovsky <boris.ostrovsky@...cle.com>, Xen Devel <Xen-devel@...ts.xensource.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>, linux-next@...r.kernel.org, linux-kernel@...r.kernel.org, Vitaly Kuznetsov <vkuznets@...hat.com>, Andy Lutomirski <luto@...nel.org>, Mathias Krause <minipli@...glemail.com>, Thomas Garnier <thgarnie@...gle.com> Subject: Re: linux-next: manual merge of the xen-tip tree with the tip tree * Juergen Gross <jgross@...e.com> wrote: > On 29/03/17 05:35, Stephen Rothwell wrote: > > Hi all, > > > > Today's linux-next merge of the xen-tip tree got a conflict in: > > > > arch/x86/xen/enlighten.c > > > > between commits: > > > > 6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86") > > 69218e47994d ("x86: Remap GDT tables in the fixmap section") > > b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup") > > > > from the tip tree and commits: > > > > 75cd32d6093e ("x86/xen: split off enlighten_pv.c") > > > > from the xen-tip tree. > > > > I dropped the xen-tip tree for today (see other conflict reports), > > please get together and sort these out, thanks. > > > > Hmm, seems to be a rather bad timing for the series of Vitaly. > > What is the best way to resolve those conflicts? A rebase of Vitaly's > patches seems to be required in any case. > > Should I rebase the Xen tree on current tip? This seems to be rather > easy, but I think this will work only if I can be sure the current tip > tree contents will all be merged by Linus before the Xen tree. That's certainly very likely, -tip trees all go in very early in the merge window. > I could try to cherry pick the patches from tip where Vitaly's patches > have conflicts with, but I think this could lead to a lot of patches > to take. Nor is it desirable as a workflow. I'd suggest the following: in about a week I can guarantee a working tip:x86/mm base with most of the 5-level paging patches applied that you could base Xen patches on. Unfortunately, right now there's at least one regression with those changes that needs to be properly fixed before it's a suitable base tree. The fix already exists, it just needs to be tested and the whole tree needs to cook for a few days to be dependable for Xen as a base. > Or we could delay Vitaly's series until tip has been merged, but this > will either delay some other Xen patches depending on (or conflicting > with) Vitaly's patches or would make the rebase for Vitaly more > difficult. So my suggestion would be: could you delay 75cd32d6093e for a week, and then merge it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on the first day of the merge window so there shouldn't be any ordering problems. Thanks, Ingo
Powered by blists - more mailing lists