Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU

James Bottomley
2024-03-01T04:18:33Z

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