On Wed 20-11-24 17:39:09, Kent Overstreet wrote: > Michal's (as well as Steve's) behaviour in the memory allocation > profiling review process was, in my view, unacceptable (this included > such things as crashing our LSF presentation with ideas they'd come up > with that morning, and persistent dismissive axegrinding on the list). > The project was nearly killed because of his inability to listen to the > reasons for a design and being stubbornly stuck on his right to be heard > as the maintainer. Couple of entry points that might be helful for that. https://lore.kernel.org/all/YxBc1xuGbB36f8zC@xxxxxxxxxxxxxx/ I have expressed my concerns and set expectations to move the work forward. I've had couple of back and forth with Suren about specifics of overhead assumptions from the stack unwinding IIRC. For the first non-RFC version my feedback was https://lore.kernel.org/all/ZFIMaflxeHS3uR%2FA@xxxxxxxxxxxxxx/#t not really "maintenance burden only" but a request to show that alternative approaches have been explored. It was not particularly helpful that you had expected tracing people would implement the feature for you. https://lore.kernel.org/all/20230503092128.1a120845@xxxxxxxxxxxxxxxxxx/ Other people have also expressed that this is not completely impossible https://lore.kernel.org/all/ZFKNZZwC8EUbOLMv@xxxxxxxxxxxxxxx/ The rest of the email thread is mostly a combat zone that I have avoided participating as much as possible. I didn't have any reaction to v2 at all. v3 was aiming to be merged and I've stepped up as there was no single review at the time https://lore.kernel.org/all/Zctfa2DvmlTYSfe8@tiehlicka/ I admit that I was really open that I do not like the solution and I've said reasons for that. Allocator APIs have always been a large mess of macros, static inlines that makes it really far from free to maintain and alternative ways should be considered before going that route. I was also clear that support by MM people was necessary to get this merged. I have explicitly _not_ NAKed the series and backed off for you guys to gain that support. So essentially there was a clear outline for you and Sure how to achieve that. I would really like to hear from other maintainers. Is tnis really unacceptable maintainer behavior? I am OK to apologize but the above is in line of my understanding of how to ack properly. [...] > Next up, PF_MEMALLOC_NORECLAIM over Michal's nack - I was wrong there, I > only did it because it really seemed to me that Michal was axe grinding > against _anything_ I was posting, but I still shouldn't have and that > was more serious infraction in my view; that sort of thing causes a real > loss of trust, and no I will not do it again. Yes, this is simply unacceptable! Just to put full context. We are talking about eab0af905bfc ("mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN"). I have pushed back on that https://lore.kernel.org/all/Zbu_yyChbCO6b2Lj@tiehlicka/ Rather than searching for support elsewhere you have completely bypassed the whole MM community including Andrew and pushed that hidden in bcachefs PR. This is breaking trust model we are all relying on. I am cutting the rest of as something that is not really material to maintainership discussion. -- Michal Hocko SUSE Labs
