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.
