Hi Geert,
Am 05.07.2023 um 19:24 schrieb Geert Uytterhoeven:
We do not really have a way to record comments in git history
after the fact. The best you can do is to reply to the email thread
where the patch was submitted. When people follow the Link:
tag to the lore archive in the original commit, they can read any follow-ups.
Does lore pick up related patches through the In-Reply-To header? In
that case it would be easiest for me to to put this comment in a cover
letter to the bugfix patch.
Lore does not do that (b4 (the tool to download patch series from lore)
usually can link a series to its previous version, though).
New replies sent to a patch submission do end up in the right thread,
so any later comments (bug reports, Reviewed/Tested-by tags, ...)
can be found easily by following the Link: tag in the commit.
OK, that's good enough for me.
Partitions that did overflow the disk size (due to 32 bit int
overflow) were not skipped but truncated to the end of the
disk. Users who missed the warning message during boot would
I am confused. So before, the partition size as seen by Linux after
the truncation, was correct?
No, it was incorrect (though valid).
On a 2 TB disk, a partition of 1.3 TB at the end of the disk (but not
extending to the very end!) would trigger a overflow in the size
calculation:
sda: p4 size 18446744071956107760 extends beyond EOD,
Oh, so they were not "truncated to the end of the disk"?
Not by the RDB parser, but truncation happens ultimately. I should have
copied the second instance of that message from Christian's log:
sda: p4 size 18446744071956107760 extends beyond EOD, truncated
The core partition code later sanity checks the partition data and
truncates (see block/partitions/core.c:blk_add_partition())
Cheers,
Michael
