[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4edgqqhbwn56jnz3fraowgyuwhjs33uw3545mnksxwrng42wa6@fbaqfqlhru7g>
Date: Sat, 22 Feb 2025 10:30:34 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Martin Uecker <uecker@...raz.at>
Cc: Dan Carpenter <dan.carpenter@...aro.org>,
Greg KH <gregkh@...uxfoundation.org>, Boqun Feng <boqun.feng@...il.com>,
"H. Peter Anvin" <hpa@...or.com>, Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
Christoph Hellwig <hch@...radead.org>, rust-for-linux <rust-for-linux@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>, David Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org,
ksummit@...ts.linux.dev, Justin Stitt <justinstitt@...gle.com>,
Kees Cook <keescook@...omium.org>
Subject: Re: Rust kernel policy
On Thu, Feb 20, 2025 at 03:09:21PM +0100, Martin Uecker wrote:
> We added checked arhithmetic to C23, we could add saturating
> math to C2Y if this is needed. (although I admit I do not fully
> understand the use case of saturating math, a saturated value
> still seems to be an error? Statistics, where it does not matter?)
Saturating is mainly for refcounts. If the refcount overflows, you want
it to saturate and _stay there_, because you no longer know what the
value should be so never freeing the object is the safest option.
Powered by blists - more mailing lists