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... BTW - (after getting emails for three different people about this, heh) I do want to apologize for things getting this heated the other day, but I need to also tell you why I reacted the way I did. Firstly, it's nothing personal: I'm not axe grinding against you (although you were a major source of frustration for myself and Suren in the memory allocation profiling discussions, and I hope you can recognize that as well). But I do take correctness issues very seriously, and I will get frosty or genuinely angry if they're being ignored or brushed aside. The reality as that experience, and to be frank standards of professionalism, do vary within the kernel community, and I have had some _outrageous_ fights over things as bad as silent data corruption bugs (introduced in code I wrote by people who did not CC me, no less; it was _bad_, and yes it has happened more than once). So - I am _not_ inclined to let things slide, even if it means being the asshole at times. Thankfully, most people aren't like that. Dave, Willy, Linus - we can be shouting at each other, but we still listen, and we know how not to take it personally and focus on the technical when there's something serious going on. Usually when one of us is shouting, you'll find there's a good reason and some history behind it, even if we also recognize the need to try to tone things down and not be _too_ much of an asshole. Linus was reminding me of that yesterday... So for the record: I'm not trying to roadblock you or anyone else, I'm just trying to make sure we all have shit that _works_. And I have been noticing you stepping up in discussions more, and I'd like to encourage that, if I may. MM has been lacking in strong technical leadership for a _long_ time - Andrew's great on the process side, he makes sure things move along, but we haven't had anyone who's trying to keep everything important in their heads, who's able to point out to people where their work fits in the larger picture, and there's been some messy things that have built up over time. And a word on technical leadership - it doesn't mean being the one who's "right" all the time, although it does involve a lot of saying "no" to people. The people who seem the smartest - it's not raw IQ that they've got (although that helps!), it's the ability to listen and quickly incorporate other people's ideas without drama or attachment, and the ability to maintain perspective; notice what people are blocked on, without getting stuck on it, and think about how it fits into the wider perspective. Cheers, Kent
