Re: [PATCH] libfs: fix accidental overflow in offset calculation
From: Al Viro
Date: Fri May 10 2024 - 00:48:24 EST
On Fri, May 10, 2024 at 03:26:08AM +0000, Justin Stitt wrote:
> This feels like a case of accidental correctness. You demonstrated that
> even with overflow we end up going down a control path that returns an
> error code so all is good.
No. It's about a very simple arithmetical fact: the smallest number that
wraps to 0 is 2^N, which is more than twice the maximal signed N-bit
value. So wraparound on adding a signed N-bit to non-negative signed N-bit
will always end up with negative result. That's *NOT* a hard math. Really.
As for the rest... SEEK_CUR semantics is "seek to current position + offset";
just about any ->llseek() instance will have that shape - calculate the
position we want to get to, then forget about the difference between
SEEK_SET and SEEK_CUR. So noticing that wraparound ends with negative
is enough - we reject straight SEEK_SET to negatives anyway, so no
extra logics is needed.
> However, I think finding the solution
> shouldn't require as much mental gymnastics. We clearly don't want our
> file offsets to wraparound and a plain-and-simple check for that lets
> readers of the code understand this.
No comments that would be suitable for any kind of polite company.