On Tue, Feb 09, 2021 at 01:11:03PM -0800, Andrew Morton wrote:

quoted

quoted

It would be best to merge [1/4] via the btrfs tree.  Please add my

Acked-by: Andrew Morton <akpm@linux-foundation.org>


Although I think it would be better if [1/4] merely did the code
movement.  Adding those BUG_ON()s is a semantic/functional change and
really shouldn't be bound up with the other things this patch series
does.

I proposed this too and was told 'no'...

<quote>
If we put in into a separate patch, someone will suggest backing out the
patch which tells us that there's a problem.
</quote>
	-- https://lore.kernel.org/lkml/20201209201415.GT7338@casper.infradead.org/ (local)

Yeah, no, please let's not do this.  Bundling an offtopic change into
[1/4] then making three more patches dependent on the ontopic parts of
[1/4] is just rude.

I think the case for adding the BUG_ONs can be clearly made.  And that
case should at least have been clearly made in the [1/4] changelog!

(Although I expect VM_BUG_ON() would be better - will give us sufficient
coverage without the overall impact.)

I'm ok with VM_BUG_ON()

Let's please queue this up separately.

Ok can I retain your Ack on the move part of the patch?  Note that it does
change kmap_atomic() to kmap_local_page() currently.

Would you prefer a separate change for that as well?

Ira

PS really CC'ing Matthew now...