Hi Geert,
Am 29.06.18 um 21:10 schrieb Geert Uytterhoeven:
The question is - can writes to the disk cause any damage to data on the
disk, as seen by old OS versions? If the answer is no, we won't need the
option after all.
You mean someone relying on the parameters of his RDB to overflow using
32-bit calculations, and still have valid offsets on the disk so it's usable?
I think that would need hand-crafting an RDB, if possible at all.
And writing to it on AmigaOS 4.0 or any other OS doing proper 64-bit
calculations would write to the wrong locations, too.
IMHO not something to consider.
Something like that. But I haven't stopped for long enough to work out
if that was even possible.
How does the user come to know about this kernel option? Will you print
its name in kernel log?
Depends on how easy we want to make it for users. If I put a BUG() trap
with the check, the resulting log section will point to a specific line
in block/partitions/amiga.c, from which the override option will be
obvious. But that might be a little too opaque for some...
Please don't use BUG(), unless your goal is to attract attention (from
Linus, who dislikes BUG()!).
I'd rather not abuse his patience. Thanks for the hint.
Using BUG() would be a nice way to DoS someones machine by plugging in
a USB stick with a malformed RDB.
I guess I deserved that. But BUG() doesn't panic now, does it? The ones
I saw did allow the kernel to happily carry on.
The one in asm-generic does call panic().
Ouch - that explains Linus's aversion.
The m68k one calls __builtin_trap(), which may cause a trap (and panic?) or
do nothing, depending on gcc version, I think.
The trap doesn't cause a panic for me. Might rely on the trap vector
being set up right (which we can rely on at partition scan time), and
the context though. But if m68k is the odd one out in gracefully
handling BUG(), better leave it.
Cheers,
Michael
Gr{oetje,eeting}s,
Geert
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
