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

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Christian,

please stop placing your replies underneath the previous mail's 
signature separator. There are mail clients that won't copy such text 
when composing a reply.

Am 02.07.2023 um 21:34 schrieb Christian Zigotzky:
>
>
> On 2. Jul 2023, at 10:56, Christian Zigotzky <chzigotzky@xenosoft.de> wrote:
>
> On 2. Jul 2023, at 09:55, Martin Steigerwald <martin@lichtvoll.de> wrote:
>
> How many end users are you speaking of?
>
> Back then I thought I was the only one using a hard disk with mixed
> Amiga/Linux RDB setup.
>
> Best,
>
>
> Martin
>
>
>
> A lot.  I am speaking about the new A-EON machines.
>
>
>
> The end users have to fix their  RDBs if they want to use the new patched kernels.

So what you're saying is that you have let your end users use RDB 
partitions on the old kernels that had a bug against them in the RDB 
code for eleven years, and proposed bugfixes for as long, patches to 
resolve the problem submitted to linux-block for the last five years, 
and you never once stopped to investigate what the ramifications of this 
bug were, and what the consequences of the proposed bugfix would be?

The discussion of this bug among Martin, Joanne and Geert didn't leave a 
lot to imagination as regards data corruption potential.

> But a normal user can’t edit the RDB manually. What can we do for the end users?

End users can use whatever tool they happened to use to partition the 
disk in the first instance, and correct the partition table that way.

Leaving 8 GB unused at the end of the disk can't be some feature of 
Amiga partition editors, leastways not one that can't be overridden?


But if you want to support your large userbase by a convenient solution, 
may I suggest you write a small tool that gets the disks's end cylinder 
from the RDB (field rdb_HiCylinder, offset 0x8c), then walk the 
partition list starting from rdb_PartitionList for the first partition 
block, then pb_Next for the next one, find the last valid partition 
(where pb_Next is 0xffffffff), and check whether the partition size 
calculation for that partition (in 32 bit arithmetic) would cause the 
partition end to land beyond EOD. If that is the case, the old kernel 
code would have truncated that partition to exactly EOD, and you have to 
change the partition end cylinder value (offset 0xa8 from the start of 
that partition block) to the value of rdb_HiCylinder. Adjust the 
partition checksum (offset 0x8) by the difference of the old and new 
values (i.e. add (old-new) to the checksum stored there) and you should 
have a valid partition to the end of the disk.

Might be a bit tough in a shell script but not too hard in Perl or Python.

Putting that kind of fix in the kernel would be asking Jens and Linus 
(and quite a few others) to yell at me and call me names, and for very 
good reason (but of course you can always do that in kernels you 
distribute to your end users).

Cheers,

	Michael