[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20171116.104318.1816177872306749082.davem@davemloft.net>
Date: Thu, 16 Nov 2017 10:43:18 +0900 (KST)
From: David Miller <davem@...emloft.net>
To: daniel@...earbox.net
Cc: torvalds@...ux-foundation.org, mingo@...nel.org,
peterz@...radead.org, akpm@...ux-foundation.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
ast@...nel.org
Subject: Re: [GIT] Networking
From: Daniel Borkmann <daniel@...earbox.net>
Date: Wed, 15 Nov 2017 23:15:20 +0100
> On 11/15/2017 09:19 PM, Linus Torvalds wrote:
>> On Wed, Nov 15, 2017 at 3:33 AM, David Miller <davem@...emloft.net> wrote:
>>>
>>> Highlights:
>>
>> Lowlights:
>>
>> 1) it duplicated a commit from the hrtimer tree, which had been
>> cleaned up and rewritten, but then merging the second copy of the
>> commit re-introduced the bad code that had been cleaned up.
>>
>> I'm talking about commits
>>
>> - 7d9285e82db5:
>> perf/bpf: Extend the perf_event_read_local() interface, a.k.a.
>> "bpf: perf event change needed for subsequent bpf helpers"
>> - 97562633bcba
>> bpf: perf event change needed for subsequent bpf helpers
>>
>> where apparently there was no discussion between the groups about the
>> subsequent changes.
>>
>> And this must have shown up in linux-next as a conflict, but no
>> mention of it from either the perf event tree or the networking tree
>> merge.
>>
>> Although it is of course possible that depending on merge order, the
>> problem never showed up in next.
>
> Sorry about that, it was discussed that the patch in [1] would get
> routed through net-next and again cherry-picked from tracing folks
> due to conflicting changes in perf event tree that were being worked
> on to avoid later merge conflicts - clearly that didn't give the
> desired result.
>
> There was a subsequent discussion in [2] but not sure if cherry-picking
> 0d3d73aac2ff ("perf/core: Rewrite event timekeeping") into net-next
> would have made it better or worse. We'll have a bpf sub-tree up and
> running soon for the next development cycle that can be pulled from
> by different parties when needed; potentially this could reduce such
> conflicts between trees in future. Sorry for the trouble.
Yeah, sorry about all of this.
I had hoped that since the patch was being appied to both trees in
order to avoid merge problems, no modifications would have been made
to the change at either end. This obviously didn't happen.
I also didn't communicate the issue to you clearly in the pull
request, and for this I apologize.
As Daniel says, we realize that bpf is breaching multiple subsystems
more and more so over time, and we hope a bpf GIT tree will help
alleviate this moving forward.
Thanks!
Powered by blists - more mailing lists