Re: [PATCH v3] block: bugfix for Amiga partition overflow check patch

[Michael Schmitz <schmitzmic@gmail.com>]

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