New kernels

[xeno74]

I reported the issue with the new patch to the kernel developers today.

Link: [PATCH] block: bugfix for Amiga partition overflow check patch -- linux-block.vger.kernel.org mailing list

[xeno74]

Now that may be a new bug... or just a filesystem created with incorrect
assumptions about partition size.

That is the partition that had reported:

> sda: p4 size 18446744071956107760 extends beyond EOD, truncated

with my patches backed out? I wonder what size mkfs used when creating
the filesystem?

The calculated size was clearly incorrect, but the truncated size may
also be incorrect. The truncated size is likely that of a partition
extending to the end of the disk, but your actual p4 size may have been
smaller (your parted -l output had 1992GB which is 8 GB shorter than to
EOD).

On the face of it, this does not look like a new bug in the RDB
partition code, but I'd rather verify that by inspecting the RDB
contents and carrying out the calculations by hand.

Can you please send a copy of the RDB (first few kB of the disk,
something like dd if=/dev/sda of=rdb-sda.img bs=512 count=16 should do),
and the output of cat /proc/partitions when running a kernel from before
my RDB patches?

> I can't mount the ext4 partition on the RDB disk and booting isn't
> possible as well.

I suppose the ext4 filesystem must be resized to match the actual
partition size. I don't think that can be done on a live, mounted
filesystem. You may have to hook up the disk to another Linux host for
that, and use resize2fs there (or boot a ramdisk containing that tool).

Cheers,

Michael

Copy of the RDB: rdb-sda.img

cat /proc/partitions:

Code: Select all

major minor  #blocks  name

   8        0 1953514584 sda
   8        1     119088 sda1
   8        2    2100096 sda2
   8        3  672670920 sda3
   8        4 1278623448 sda4
  11        0    1048575 sr0
   8       32     250880 sdc
   8       33     249856 sdc1
   8       16  234431064 sdb
   8       17  144364512 sdb1
   8       18          1 sdb2
   8       19   18500608 sdb3
   8       20   40717312 sdb4
   8       21   14684160 sdb5
   8       22   16161792 sdb6
   8       48       1440 sdd
   8       49       1439 sdd1

[xeno74]

Hi All,

I released the second alpha of kernel 6.5 for the X1000 and X5000 today.

New:

• Linux 6.5 Should Spend Less Time Waiting On PCIe Devices -- phoronix.com
• PowerPC updates 6.5-1
• PCI udpates
• SCSI updates (including NVMe updates)
• ATA updates
• DMA mapping updates
• DRM updates (including Radeon updates)
• Sound updates (including USB audio updates)
• Ext4 updates
• XFS updates
• Linux Git log
• Phoronix articles, reviews and news stories covering Linux 6.5

We still need the revert_amiga.c.patch because of the issue with accessing of partitions on disks with an Amiga partition table.

Download: linux-image-6.5-alpha2-X1000_X5000.tar.gz



Please test the kernels.

Thanks,
Christian

[musa]

Hi
Debian 32 Trixie/sid boot with vmlinux-6.5_a2
Have a nice day

[xeno74]

Hi
Debian 32 Trixie/sid boot with vmlinux-6.5_a2
Have a nice day

Great! Thanks a lot for testing!

[xeno74]

(A) Track (also cylinder), (B) Sector, (C) Block, (D) Cluster

Thanks, casual inspection of this RDB does show that indeed a value of -1 is used as pb_next in partition slot 4 (and 5).

The disk geometry is defined as 3 heads, 16 sectors per track (48 sectors per cylinder) and 81396441 cylinders which matches your 2 TB disk size.

The first partition begins at cylinder 43 and ends at cylinder 5004, matching the 119088 k (k == 1024 bytes) below.

Partition 2 begins at cylinder 5005, ends at 92508, size 2100096 again as below.

Partition 3 begins at cylinder 92509, ends at 28120463, size 672670920 as below.

Partition 4 begins at cylinder 28120464, ends at 81068868, size 1270041720, different from the size shown in your /proc/partitions log.

The disk ends at cylinder 81396440, so a partition 4 extending to the end of the disk would have size 1278623448, which is what your log shows.


cat /proc/partitions:

major minor #blocks name

8 0 1953514584 sda
8 1 119088 sda1
8 2 2100096 sda2
8 3 672670920 sda3
8 4 1278623448 sda4

I have (disk image on sdb, patches applied):
8 20 1270761720 sdb4

which matches what I calculated by hand above.

With an old kernel that does not have the RDB fixes, I get the same partition size as you report. That size is the result of truncation to EOD (the miscalculated size of 18446744071956107760 exceeds the device size).

Creating the filesystem on an unpatched kernel will use that incorrect partition size. I'm sorry to say I cannot see a new RDB partition bug her, just the result of undefined behaviour due to overflowing a 32 bit nr_sect size calculation in the old RDB code.


If you cannot shrink the filesystem, you will have to edit the partition table to extend p4 to the end of the disk. Just replace the partition 4 pb->pb_Environment[10] (at offset 0x8a8, current value 0x04d50344) by 0x04da02d8. As far as I can see, there is no adjustment to the partition block checksum required, as the checksummed block of 160 bytes ends just before the location of the partition's low and high cylinder addresses....

I'd best verify that a patched RDB actually works...

[Hypex]

Testing kernel 6.5.0-a2 now and all seems to be working fine.

[xeno74]

Testing kernel 6.5.0-a2 now and all seems to be working fine.

Fantastic! Thank you for testing the alpha2!

[xeno74]

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.

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"):

Partitons 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
go on to create a filesystem with a size exceeding the
actual partition size. Now that the 32 bit overflow has been
corrected, such filesystems may refuse to mount with a
'filesystem exceeds partition size' error. Users should
either correct the partition size, or resize the filesystem
before attempting to boot a kernel with the RDB fixes in
place.

Reported-by: Christian Zigotzky <[email protected]>
Fixes: b6f3f28f60 ("block: add overflow checks for Amiga partition support")
Message-ID: [email protected]
Cc: <[email protected]> # 6.4
Link: https://lore.kernel.org/r/024ce4fa-cc6d ... enosoft.de
Signed-off-by: Michael Schmitz <[email protected]>
Tested-by: Christian Zigotzky <[email protected]>

--

Changes since v1:

- corrected Fixes: tag
- added Tested-by:
- reworded commit message to describe filesystem partition
size mismatch problem
---
block/partitions/amiga.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/partitions/amiga.c b/block/partitions/amiga.c
index ed222b9c901b..506921095412 100644
--- a/block/partitions/amiga.c
+++ b/block/partitions/amiga.c
@@ -90,7 +90,7 @@ int amiga_partition(struct parsed_partitions *state)
}
blk = be32_to_cpu(rdb->rdb_PartitionList);
put_dev_sector(sect);
- for (part = 1; blk>0 && part<=16; part++, put_dev_sector(sect)) {
+ for (part = 1; (s32) blk>0 && part<=16; part++, put_dev_sector(sect)) {
/* Read in terms partition table understands */
if (check_mul_overflow(blk, (sector_t) blksize, &blk)) {
pr_err("Dev %s: overflow calculating partition block %llu! Skipping partitions %u and beyond\n",
--
2.17.1

I will try out, if I can correct them with GParted. If it works, then I will write some instructions for correcting the partitions via GParted.

But now I will revert this patch until I find a simple solution for us maybe with GParted.

[Hypex]

I wonder if this bug has affected corrupted partitioning of Amiga volumes in Linux? This would go back years now to the A1 Linux days but I found I could not fully trust creating Amiga partitions in GParted or what ever tool was in use. Especially adding one which should be safe but something could always go wrong. For this reason I only trust managing Amiga partitions from OS4 and only do formatting at the most from Linux when managing them.