On Thu, 2024-02-29 at 23:01 -0500, Kent Overstreet wrote: > On Thu, Feb 29, 2024 at 10:52:06PM -0500, Kent Overstreet wrote: > > On Fri, Mar 01, 2024 at 10:33:59AM +0700, James Bottomley wrote: > > > On Thu, 2024-02-29 at 22:09 -0500, Kent Overstreet wrote: [...] > > > > Let's _not_ go that route in the kernel. I have pointy sticks > > > > to brandish at people who don't want to deal with properly > > > > handling errors. > > > > > > Error legs are the least exercised and most bug, and therefore > > > exploit, prone pieces of code in C. If we can get rid of them, > > > we should. > > > > Fuck no. > > > > Having working error paths is _basic_, and learning how to test > > your code is also basic. If you can't be bothered to do that you > > shouldn't be writing kernel code. Heh, that's as glib as saying people should test their C code for overcommit errors. If everyone did that there'd be no need for languages like rust. > > We are giving far too much by going down the route of "oh, just > > kill stuff if we screwed the pooch and overcommitted". > > > > I don't fucking care if it's what the big cloud providers want > > because it's convenient for them, some of us actually do care about > > reliability. Reliability has many definitions. The kernel tries to leave policy like this to the user, which is why the overcommit type is exposed to userspace. Arguing about whose workload is more important isn't really going to be helpful. > > By just saying "oh, the OO killer will save us" what you're doing > > is making it nearly impossible to fully utilize a machine without > > having stuff randomly killed. > > > > Fuck. That. > > And besides all that, as a practical matter you can't just "not have > erro paths" because, like you said, you'd still have to have a max > size where you WARN() - and _fail the allocation_ - and you've still > got to unwind. So? the point would be we can eliminate some potentially buggy error legs on small allocations. Since we have to add MAY_FAIL and error handling (which should already exist) to the larger ones. It would have no impact at all on scaling. The question of where the limit should be in the general case should probably be compile time configurable. We can probably even get the compiler to eliminate the if (err) leg with some judicious return value priming, meaning we achieve some meaningful bug density reduction for no or very few code changes. James
