[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whqXizOqcpcrqvRJ88Twi4+o=G1Y=5qsLBs5R-8uHjs+Q@mail.gmail.com>
Date: Sun, 21 Jul 2024 18:12:37 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andrew Morton <akpm@...ux-foundation.org>, Kent Overstreet <kent.overstreet@...ux.dev>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
mm-commits@...r.kernel.org
Subject: Re: [GIT PULL] non-MM updates for 6.11-rc1
On Sun, 21 Jul 2024 at 15:10, Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> - In the series "treewide: Refactor heap related implementation",
> Kuan-Wei Chiu has significantly reworked the min_heap library code and
> has taught bcachefs to use the new more generic implementation.
Bah. I think the users should probably have been converted in their
own trees, instead of having this thing that caused a somewhat nasty
conflict.
I think I sorted it out correctly, but I'm not seeing why the bcachefs
conversion was done outside the bcachefs tree.
(Ok, it's not like the conflict was all that nasty, really. It's more
that conflicts in this _kind_ of code is a bit nasty).
As it is, I do see the Ack from Kent, but I'm going to ask him to also
double-check my merge.
I see what happened in linux-next, but that state also seems different
from my tree (at a minimum, Kent also moved the tiemr_lock around a
bit too).
Anyway.. The conflict resolution looks sane to me and doesn't seem
fundamentally complex, but (a) mistakes happen and (b) it does seem
like this whole heap conversion could have happened in the bcachefs
tree.
Kent, mind checking that I didn't do something horribly horribly bad?
Linus
Powered by blists - more mailing lists