Andrew, please correct me if I miss/mess anything. > > This hunk is already in the next tree, see below please. > > > > Ah, the whole series to add shmem like code to handle hole punch/fault > races is in the next tree. It has been determined that most of this > series is not necessary. For the next tree, ideally the following > should happen: > - revert the series > 0830d5afd4ab69d01cf5ceba9b9f2796564c4eb6 > 4e0a78fea078af972276c2d3aeaceb2bac80e033 > 251c8a023a0c639725e014a612e8c05a631ce839 > 03bcef375766af4db12ec783241ac39f8bf5e2b1 > - Add this patch (if Ack'ed/reviewed) to fix remove_inode_hugepages > - Add a new patch for the handle hole punch/fault race. It modifies > same code as this patch, so I have not sent out until this is Ack'ed. > > I will admit that I do not fully understand how maintainers manage their > trees and share patches. If someone can make suggestions on how to handle > this situation (create patches against what tree? send patches to who?), > I will be happy to make it happen. > The rule is to prepare patches against the next tree and deliver patches to linux-mm with AKPM, linux-kernel cced. The authors and maintainers of the current code your patches change should also be cced. And those guys you want to get ack and comments. In this case, you should first ask Andrew to withdraw the 4 commits. Then send your new patches, one after another, one problem a patch. Best Wishes Hillf -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>