On Fri, May 22, 2026 at 10:31:41AM -0600, Nico Pache wrote: > On Fri, May 22, 2026 at 10:20 AM Lorenzo Stoakes <[email protected]> wrote: > > There's some kind of confusion here. > > > > This series isn't suited for 7.2. > > > > Sorry but Zi's series, unless it depends on functionality here, will have > > to be rebased. > > > > People have been at conferences, people have been on leave, I've had to > > pace myself for health reasons and it seems there's been more than simply > > review comment-based changes happening here. > > > > (Again I strongly encourage, at this stage, to ONLY be making changes based > > on review, not adding ANYTHING else or changing ANYTHING else to avoid > > delays :) > > All the changes are based on review points. Very small changes in this > version; the largest being the one that you specifically argeed too.
16->17 Documentation/admin-guide/mm/transhuge.rst | 24 +++++------------- include/linux/khugepaged.h | 7 ++--- include/trace/events/huge_memory.h | 3 ++- mm/huge_memory.c | 2 +- mm/khugepaged.c | 168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------------ mm/vma.c | 6 ++--- tools/testing/vma/include/stubs.h | 3 ++- 7 files changed, 103 insertions(+), 110 deletions(-) 17->18 Documentation/admin-guide/mm/transhuge.rst | 5 +++-- include/trace/events/huge_memory.h | 3 +-- mm/khugepaged.c | 121 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------------------------- 3 files changed, 66 insertions(+), 63 deletions(-) These are not small 'very small changes'. We're nearly at rc-5, and this is a major, invasive, dangerous change that we have to get right. You've also made changes unrelated to review, repeatedly, throughout this process, which as I've told you, is causing delays. You've also throughout the review of this series done stuff like make MAJOR changes to things and _kept review tags_. You're forcing us to use git range-diff etc. to forensically check that the series is what is claimed. Dude I mean you switched to using // comment style which is not used in mm anywhere for instance? Don't do things like that and complain about delays. Honestly. Also, again, LSF happened. Other confeerences happened. Bandwidth is reduced. So again, I'm sorry, but you've been hit with some bad luck here. I really wanted this in for 7.2, and I feel bad that we couldn't make it, but you're also doing thing that's making it difficult for us. I've spent double-digits hours on your series, and I've also had work pushed out becasue of that leading me to work evenings and weekends as a result. And I'm not even going to get any credit for it :)) So while I sypmathise, really, please have empathy and realise it goes both ways, please. I'm not being mean for the sake of it, I'm pushing back because I feel this is not at a stage where I'd feel confident in this being merged at this time. And it's very much a regret, as I _really_ wanted us to have it in this time. But life and circumstances and the issues mentioned above have intervened, sadly. > > > > > Also - shouldn't mm-unstable already have mm-hotfixes-unstable in it? > > > > I think in mm-next we will have an stable branch, that everything is > > based on, where things go once review is complete and things are mergeable. > > > > And a separate hotfixes branch based on Linus's tree. > > > > That would avoid issues like this :) > > Im sorry im new to this, but I really dont think this tiny error, and > something that I'd confirmed with Andrew beforehand deserves NAKing > and defering it. Ive worked through my PTO to clean up some of these > review nits just to get it in 7.2. I even through this through my > rounds of testing today before resending. The issue wasn't the error (though it wasn't tiny...!), it's the state of review. There was fresh review comments from a few days ago, and there's big diffs between revisions. You've also made unrelated changes as you have done throughout the series. As I said above, I'm sorry that you spent time in your PTO on this, but we cannot rush this in when things are not clearly ready yet, and I am not confident in this being ready at this stage. > > > > > > > > > The intent wasn't that this is a hotfix, just that this was the > > > closest base before the v17 that is already in the tree. > > > > The convention is that [PATCH ... <branch>] indicates the target of the > > changes. Putting the hotfixes branch there implies it's a hotfix. > > Sorry I thought the <branch> was what base you used. I mean, sure there's clearly confusion here as you sent [PATCH 7.2 v16 ...] (against an unreleased kernel version) then a branch specifier then the hotfixes one... Anyway sure, it's fine, I've made vastly more dumb mistakes than that myself, nobody minds, but it's concerning as by convention [PATCH ... <mm->hotfixes<whatever>] generally is taken to mean 'please rush this to hotfixes!' :) So be careful with that please! > > > > > So please be careful with that in future :) > > Yes will do for sure. Thanks! > > > > > > > > > Sorry for the confusion, hopefully Andrew can still apply it to the > > > correct tree. > > > > I'm not even sure what's best for that at this stage given we have > > conflicts and this has to be delayed until 7.3. > > > > I wonder if given that we should not have this in mm-unstable at all and > > just wait it out until the next cycle begins? Review can happen > > concurrently. > > I still dont see why this has to be deferred, I was working with > Andrew to prevent merge headaches. I've explained the why above, and David and I co-maintain THP so I feel that ultimately given the blood, sweat and tears we've put into THP review we ought to have some input on this :) Thanks, Lorenzo
