On Tue, 9 Feb 2021 12:52:49 -0800 Ira Weiny <[email protected]> wrote:
> On Tue, Feb 09, 2021 at 11:09:31AM -0800, Andrew Morton wrote: > > On Tue, 9 Feb 2021 16:11:23 +0100 David Sterba <[email protected]> wrote: > > > > > On Fri, Feb 05, 2021 at 03:23:00PM -0800, [email protected] wrote: > > > > From: Ira Weiny <[email protected]> > > > > > > > > There are many places where kmap/<operation>/kunmap patterns occur. We > > > > lift > > > > these various patterns to core common functions and use them in the > > > > btrfs file > > > > system. At the same time we convert those core functions to use > > > > kmap_local_page() which is more efficient in those calls. > > > > > > > > I think this is best accepted through Andrew's tree as it has the > > > > mem*_page > > > > functions in it. But I'd like to get an ack from David or one of the > > > > other > > > > btrfs maintainers before the btrfs patches go through. > > > > > > I'd rather take the non-mm patches through my tree so it gets tested > > > the same way as other btrfs changes, straightforward cleanups or not. > > > > > > This brings the question how to do that as the first patch should go > > > through the MM tree. One option is to posptpone the actual cleanups > > > after the 1st patch is merged but this could take a long delay. > > > > > > I'd suggest to take the 1st patch within MM tree in the upcoming merge > > > window and then I can prepare a separate pull with just the cleanups. > > > Removing an inter-tree patch dependency was a sufficient reason for > > > Linus in the past for such pull requests. > > > > It would be best to merge [1/4] via the btrfs tree. Please add my > > > > Acked-by: Andrew Morton <[email protected]> > > > > > > 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/[email protected]/ 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.) Let's please queue this up separately.
