Hi Adrian,
Am 04.07.2023 um 17:48 schrieb John Paul Adrian Glaubitz:
Have we actually agreed now that this is a bug and not just an effect of the
corrupted RDB that Christian provided?
The RDB was perfectly fine. Due to 32 bit integer arithmetic overflow,
old RDB code passed an incorrect partition size to put_partition(),
and instead of rejecting a partition that extends past the end of the
disk, put_partition() truncated the size.
OK, so using "-1" as an end-of-disk partition marker is fine, but it was just
the partition size recorded in Christian's RDB that was incorrect, correct?
No, the partition size in the RDB was correct (valid, end cylinder
before end of disk). The partition size seen by user space tools when
running the old kernels was incorrect. That lead to the filesystem size
exceeding the partition size, which only came to light once the overflow
fixes had gone in.
I know it does sound like semantic sophism, but we have to be clear that
what the user put in the partition block is definite. I haven't had much
luck with heuristics in kernel code lately...
Jens - is the bugfix patch enough, or do you need a new version of the
entire series?
But the series has already been applied and released in 6.4, hasn't it?
That's right - I wasn't sure whether it had already gone upstream (but
even then, squeezing a bugfix in with an accepted patch isn't usually done).
It's even released already ;-). That's why Christian ran into the problem in the
first place.
I had hoped he'd spotted it in linux-block ...
Cheers,
Michael
Adrian
