Hi Michael,
On Tue, Jul 4, 2023 at 9:30 PM Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
On 4/07/23 19:20, Geert Uytterhoeven wrote:
On Tue, Jul 4, 2023 at 7:50 AM Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
Making 'blk' sector_t (i.e. 64 bit if LBD support is active)
fails the 'blk>0' test in the partition block loop if a
value of (signed int) -1 is used to mark the end of the
partition block list.
This bug was introduced in patch 3 of my prior Amiga partition
support fixes series, and spotted by Christian Zigotzky when
testing the latest block updates.
Explicitly cast 'blk' to signed int to allow use of -1 to
terminate the partition block linked list.
That's the explanation for what this patch does.
The below is not directly related to that, so IMHO it does not
belong in the description of this patch.
Yes, I realize that. I had hoped that by way of the Fixes: tag, people
would be able to relate that comment to the correct commit. Might be a
little circuitous ...
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.
Testing by Christian also exposed another aspect of the old
bug fixed in commits fc3d092c6b ("block: fix signed int
overflow in Amiga partition support") and b6f3f28f60
("block: add overflow checks for Amiga partition support"):
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"?
That's only noted somewhere inside put_partition. The effective
partition size seen by the kernel and user tools is then that of a
partition extending to EOD (in Christian's case a full 8 GB more than
recorded in the partition table).
go on to create a filesystem with a size exceeding the
actual partition size. Now that the 32 bit overflow has been
But if Linux did see the correct size, mkfs would have used the correct
size, too, and the size in the recorded file system should be correct?
mkfs used what the old kernel code gave as partition size. That did
'seem' correct at that time, but after the overflow fixes (which prevent
other partition miscalculations, which in Martin's case caused
partitions to overlap), the partitions size is actually correct and
smaller than the filesystem size.
I have a hunch I don't explain myself very well.
;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
