On Wed, Nov 20, 2024 at 05:55:10PM -0500, Kent Overstreet wrote: > On Wed, Nov 20, 2024 at 05:39:19PM -0500, Kent Overstreet wrote: > > On Wed, Nov 20, 2024 at 03:21:06PM -0700, Shuah Khan wrote: > > > On 11/20/24 14:37, Shuah Khan wrote: > > > > On 11/20/24 14:20, Kent Overstreet wrote: > > > > > On Wed, Nov 20, 2024 at 02:12:12PM -0700, Shuah Khan wrote: > > > > > > On 11/20/24 13:34, Kent Overstreet wrote: > > > > > > > On Wed, Sep 04, 2024 at 12:01:50PM -0600, Shuah Khan wrote: > > > > > > > > On 9/2/24 03:51, Kent Overstreet wrote: > > > > > > > > > On Mon, Sep 02, 2024 at 11:39:41AM GMT, Michal Hocko wrote: > > > > > > > > > > On Mon 02-09-24 04:52:49, Kent Overstreet wrote: > > > > > > > > > > > On Mon, Sep 02, 2024 at 10:41:31AM GMT, Michal Hocko wrote: > > > > > > > > > > > > On Sun 01-09-24 21:35:30, Kent Overstreet wrote: > > > > > > > > > > > > [...] > > > > > > > > > > > > > But I am saying that kmalloc(__GFP_NOFAIL) _should_ fail and return NULL > > > > > > > > > > > > > in the case of bugs, because that's going to be an improvement w.r.t. > > > > > > > > > > > > > system robustness, in exactly the same way we don't use BUG_ON() if it's > > > > > > > > > > > > > something that we can't guarantee won't happen in the wild - we WARN() > > > > > > > > > > > > > and try to handle the error as best we can. > > > > > > > > > > > > > > > > > > > > > > > > We have discussed that in a different email thread. And I have to say > > > > > > > > > > > > that I am not convinced that returning NULL makes a broken code much > > > > > > > > > > > > better. Why? Because we can expect that broken NOFAIL users will not have a > > > > > > > > > > > > error checking path. Even valid NOFAIL users will not have one because > > > > > > > > > > > > they _know_ they do not have a different than retry for ever recovery > > > > > > > > > > > > path. > > > > > > > > > > > > > > > > > > > > > > You mean where I asked you for a link to the discussion and rationale > > > > > > > > > > > you claimed had happened? Still waiting on that > > > > > > > > > > > > > > > > > > > > I am not your assistent to be tasked and search through lore archives. > > > > > > > > > > Find one if you need that. > > > > > > > > > > > > > > > > > > > > Anyway, if you read the email and even tried to understand what is > > > > > > > > > > written there rather than immediately started shouting a response then > > > > > > > > > > you would have noticed I have put actual arguments here. You are free to > > > > > > > > > > disagree with them and lay down your arguments. You have decided to > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > Yeah, enough of this insanity. > > > > > > > > > > > > > > > > > > > > so I do not think you are able to do that. Again... > > > > > > > > > > > > > > > > > > Michal, if you think crashing processes is an acceptable alternative to > > > > > > > > > error handling _you have no business writing kernel code_. > > > > > > > > > > > > > > > > > > You have been stridently arguing for one bad idea after another, and > > > > > > > > > it's an insult to those of us who do give a shit about writing reliable > > > > > > > > > software. > > > > > > > > > > > > > > > > > > You're arguing against basic precepts of kernel programming. > > > > > > > > > > > > > > > > > > Get your head examined. And get the fuck out of here with this shit. > > > > > > > > > > > > > > > > > > > > > > > > > Kent, > > > > > > > > > > > > > > > > Using language like this is clearly unacceptable and violates the > > > > > > > > Code of Conduct. This type of language doesn't promote respectful > > > > > > > > and productive discussions and is detrimental to the health of the > > > > > > > > community. > > > > > > > > > > > > > > > > You should be well aware that this type of language and personal > > > > > > > > attack is a clear violation of the Linux kernel Contributor Covenant > > > > > > > > Code of Conduct as outlined in the following: > > > > > > > > > > > > > > > > https://www.kernel.org/doc/html/latest/process/code-of-conduct.html > > > > > > > > > > > > > > > > Refer to the Code of Conduct and refrain from violating the Code of > > > > > > > > Conduct in the future. > > > > > > > > > > > > > > I believe Michal and I have more or less worked this out privately (and > > > > > > > you guys have been copied on that as well). > > > > > > > > > > > > Thank you for updating us on the behind the scenes work between you > > > > > > and Michal. > > > > > > > > > > > > I will make one correction to your statement, "you guys have been copied on > > > > > > that as well" - which is inaccurate. You have shared your email exchanges > > > > > > with Michal with us to let us know that the issue has been sorted out. > > > > > > > > > > That seems to be what I just said. > > > > > > > > > > > You might have your reasons and concerns about the direction of the code > > > > > > and design that pertains to the discussion in this email thread. You might > > > > > > have your reasons for expressing your frustration. However, those need to be > > > > > > worked out as separate from this Code of Conduct violation. > > > > > > > > > > > > In the case of unacceptable behaviors as defined in the Code of Conduct > > > > > > document, the process is to work towards restoring productive and > > > > > > respectful discussions. It is reasonable to ask for an apology to help > > > > > > us get to the goal as soon as possible. > > > > > > > > > > > > I urge you once again to apologize for using language that negatively impacts > > > > > > productive discussions. > > > > > > > > > > Shuah, I'd be happy to give you that after the discussion I suggested. > > > > > Failing that, I urge you to stick to what we agreed to last night. > > > The only thing we agreed upon is that you would respond the thread > > > to update your sorting things out with Michal. > > > > ...Shall I quote you? > > > > > > > > As for the discussion, I will repeat what I said in our conversation > > > that the discussion will be lot more productive after making amends > > > with the community. I stand by that assessment. > > > > > > I will also repeat what I said that the discussion and debate is > > > outside the scope of the current issue the Code of Conduct Committee > > > is trying to resolve. > > > > > > I didn't pick up on your desire to apologize after the discussion in > > > our conversation. > > > > > > Are you saying you will be happy to make amends with an apology after > > > the discussion and debate? > > > > Look, I just want to be done with this, so let me lay it all out as I > > see it, starting from the beginning of where things went off the rails > > between myself and Michal: > > > > 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. > > > > In my view, being a good maintainer has a lot more to do with > > stewardship and leadership, than stubbornly insisting for - whatever > > that was. In any event, that was where I came to the conclusion "I just > > cannot work that guy". > > > > 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. > > > > The subsequent PF_MEMALLOC_NORECLAIM discussion was such a trainwreck > > that I don't think I will go into it. Except to say that yes, if it > > makes you happy, I shouldn't have used that language and I won't do it > > again. > > > > But I do have to call out you, the CoC board's behaviour, and I think > > that ony fair since you call out other people's behaviour publically. > > > > Greg's behaviour when he approached me at Plumbers was beyond > > unprofessional, and since it wasn't exactly public and you guys have > > already heard about it privately I won't repeat exactly what happened, > > but it is an issue. > > > > Shuah, you weren't much better. > > > > There were concerns raised in the recent CoC enforcement thread, by > > someone with experience in such matters, that your aproach seemed > > extremeely heavy handed and I find myself in 100% agreement. > > > > The approach you take is that of a bad HR department: all about image, > > no understanding. When tensions arise, it's important get to the bottom > > of things, to at least try to take the time to listen with an open mind. > > People have real frustrations, and it's amazing what you can learn and > > what you can accomplish by having real conversations. > > > > But that's not what you guys do: you say "Ok, if someone's being too > > much of an asshole, we'll just be an even bigger asshole!". > > > > No. Cut that out. > > > > I've done the hard work of stepping in and building bridges when > > relations have broken down (on quite a large scale), so I'm offended by > > what you guys do. > > Now, I've said two things I'll do differently, or not do in the future. > > Michal, would you be willing to consider changing your approach a bit in > similar situations? Try to lead a little bit less by "I'm the mainainer, > my concerns must be addressed" and a little bit more by incorporating > the best of everyone's ideas, and showing respect to others who have > studied their problems, as you want to be respected as maintainer? > > Shuah, would you be willing to entertain the notion of modifying your > approach a bit as well? More in the direction of genuine conversations > and understanding, less of just following a process and slapping people > if they don't comply? > > We've got people in the community who are good at this sort of thing, > and might be willing to help if they were asked - it doesn't have to > just be you guys, and if we started encouraging this sort of thing it > could be a real learning experience for everyone. Also, let's rehash a bit: - This was worked out months ago, at Linus's behest - Scanning back through the original thread, I'm reminded by how very much not one sided this was - And there hasn't been any hope of intelligent conversation with Shuah, just broken record "we need you to do to this", so... This is no longer a process I can take seriously. Linus will pull my code, or he won't; it's out of my hands... Night all.
