On Thu, Jul 04, 2019 at 06:28:50PM -0300, Jason Gunthorpe wrote: > > It's a large patchset and it appears to be mainly (entirely?) code > > cleanups. I don't think such material would be appropriate for a late > > -rc7 merge even if it didn't conflict with lots of other higher > > priority pending functional changes and fixes! > > I see your other email you resolved the conflicts - so please let me > know if you want to proceed with dropping CH's series or not, I'll > make a special effort to get that change into tomorrows linux-next if > you want (it is already 6pm here) I spent some time this morning looking at the various conflicts, and I think Dan is right, they are mangable. In the sense we can forward a merge resolution to Linus and it is not completely crazy. Most hunks are the usual mechanical sort of conflicts. Like Stephen, only two small conflict hunks in the memremap.c give me any pause, and I'm confident with CH and Dan's help it can be resolved robustly. If Linus doesn't like it then we fall back to dropping CH's series. So, here is a fourth idea.. We remove hmm.git entirely from your workflow (ie you revert commit "cc5dfd59e375f Merge branch 'hmm-devmem-cleanup.4' into rdma.git hmm" in your local version of linux-next) and I will send hmm.git to Linus after Dan's patches and others are merged by you to Linus. With Dan and CH's help I will forward the reviewed conflict resolution. This will not disturb the -mm patch workflow at all, and you can put everything back the way it was on July 3. What do you think about this? Jason
