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, 1 Nov 2017 10:04:02 +0100 From: Ingo Molnar <mingo@...nel.org> To: Peter Zijlstra <peterz@...radead.org> Cc: Stephen Rothwell <sfr@...b.auug.org.au>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>, David Miller <davem@...emloft.net>, Networking <netdev@...r.kernel.org>, Linux-Next Mailing List <linux-next@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Yonghong Song <yhs@...com> Subject: Re: linux-next: manual merge of the tip tree with the net-next tree * Peter Zijlstra <peterz@...radead.org> wrote: > On Wed, Nov 01, 2017 at 09:27:43AM +0100, Ingo Molnar wrote: > > > > * Peter Zijlstra <peterz@...radead.org> wrote: > > > > > On Wed, Nov 01, 2017 at 06:15:54PM +1100, Stephen Rothwell wrote: > > > > Hi all, > > > > > > > > Today's linux-next merge of the tip tree got a conflict in: > > > > > > > > kernel/trace/bpf_trace.c > > > > > > > > between commits: > > > > > > > > 97562633bcba ("bpf: perf event change needed for subsequent bpf helpers") > > > > and more changes ... > > > > > > > > from the net-next tree and commit: > > > > > > > > 7d9285e82db5 ("perf/bpf: Extend the perf_event_read_local() interface, a.k.a. "bpf: perf event change needed for subsequent bpf helpers"") > > > > > > > > from the tip tree. > > > > > > So those should be the exact same patch; except for Changelog and > > > subject. Code wise there shouldn't be a conflict. > > > > So the problem is that then we have: > > > > 0d3d73aac2ff ("perf/core: Rewrite event timekeeping") > > > > which changes the code. This is a known conflict generation pattern: Git isn't > > smart enough to sort out that (probably because it would make merges too > > expensive) - and it's a bad flow in any case. > > Hmm, I thought having that same base patch in both trees would allow it > to resolve that conflict. A well.. I think that would require content level matching of a rather horrifying volume to resolve, slowing down Git merges horribly. (Maybe there's an option for Git to do that, but it's not the default I think.) Thanks, Ingo
Powered by blists - more mailing lists