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