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.
You have the right to the discussion and debate and engage the community
in the discussion. Discuss and debate away.
thanks,
-- Shuah (On behalf of the Code of Conduct Committee)
