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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx> wrote:

On 2. Jul 2023, at 09:55, Martin Steigerwald <martin@xxxxxxxxxxxx> 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





[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux