All of lore.kernel.org
 help / color / mirror / Atom feed
From: jdow <jdow@earthlink.net>
To: Michael Schmitz <schmitzmic@gmail.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Martin Steigerwald <martin@lichtvoll.de>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	linux-block@vger.kernel.org
Subject: Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB
Date: Fri, 29 Jun 2018 02:32:30 -0700	[thread overview]
Message-ID: <a0974de4-da1f-3991-8d44-4108a81a0014@earthlink.net> (raw)
In-Reply-To: <102c5f41-7fa8-267c-973a-176d3c3d4f57@gmail.com>

On 20180629 01:42, Michael Schmitz wrote:
> Hi Geert,
> 
> 
> Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
>>
>>>> Do we really need the warning?
>>>> Once the parsing is fixed doing 64-bit math, it does not matter for
>>>> Linux anymore.
>>> Well, irony of this is: In my case the RDB has been created on a machine
>>> with a native OS. So Linux warns me about something I already did so on
>>> the native OS without any warning. In this case AmigaOS 4.0.
>> Exactly.
>>
>> So moving a disk partitioned under AmigaOS 4.0 to a system running an
>> older version of AmigaOS can fail miserably. Not a Linux issue.
>> Linux also doesn't warn about disks with GPT failing to work on old MSDOS.
> 
> Would MSDOS recognize the GPT partition as 'probably FAT', and attempt
> to use it?

I believe it would fail to mount it and suggest formatting it. The key is to 
fail the mount and not risk damage to the data on it.

>> Let me clarify: what exactly would the kernel option allow? When to use it?
> 
> Whether to use it if safe (on Linux). But whatever Linux does (after
> this patch), access will go to the right area of the disk (as specified
> by the RDB) so Linux won't any longer stomp on anything that would have
> mattered to 32 bit disk drivers. So it really should be safe.

Martin pointed out something privately about RDBs I'd forgotten over the 
archeological eras gone past. The RDB values are all 32 bit unsigned longs. That 
means as long as they are properly promoted AND the file system does not barf 
from a gross overfeeding disks up to about 2^128 bytes can be supported. But you 
need a new uint128_t datatype. So for Amigas or Linux the real limitation is the 
data type and significance that flows between the RDB parser and the file 
system. That is the value that has to be considered. Then if the filesystem 
somewhere inside coughs up a hairball over some internal overflow or other and 
cannot accept say a full uint64_t maximum value of bytes with grace and polish 
it should error out when it sees an incoming disk positions off its internally 
acceptable range.

This means that any errors and failures to mount should lie with the RDB Parser, 
the filesystem, the device driver, and any intervening code between the three. 
The RDBs can express a value far greater than the number of atoms estimated to 
exist in the observable universe. So RDBs won't ever need a change for disk size 
considerations. The parser and filesystems probably and possibly, respectively, 
will.

Error out and don't mount disks or partitions that are outside the size range 
your element of the datapath from disk to user's program can handle at the first 
place this can be detected. It's the polite thing to do to a user's data rather 
than the Maxine Waters thing to do.

{^_^}

  parent reply	other threads:[~2018-06-29  9:32 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-27  1:24 Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB schmitzmic
2018-06-27  8:13 ` Martin Steigerwald
2018-06-28  3:23   ` jdow
2018-06-27  8:24 ` Martin Steigerwald
2018-06-27 20:13   ` Michael Schmitz
2018-06-27 21:20     ` Martin Steigerwald
2018-06-28  3:48       ` jdow
2018-06-28  4:58       ` Michael Schmitz
2018-06-28  6:45         ` Geert Uytterhoeven
2018-06-28  7:13           ` Martin Steigerwald
2018-06-28  9:25             ` Geert Uytterhoeven
2018-06-29  8:42               ` Michael Schmitz
2018-06-29  8:51                 ` Geert Uytterhoeven
2018-06-29  9:07                   ` Michael Schmitz
2018-06-29  9:12                     ` Geert Uytterhoeven
2018-06-29  9:25                       ` Michael Schmitz
2018-06-29 21:24                     ` Martin Steigerwald
2018-06-29 23:24                       ` Michael Schmitz
2018-06-30  0:49                         ` jdow
2018-06-29 21:17                   ` Martin Steigerwald
2018-06-29  9:32                 ` jdow [this message]
2018-06-29 21:45                   ` Martin Steigerwald
2018-06-29 23:24                     ` jdow
2018-06-30  0:44                       ` Michael Schmitz
2018-06-30  0:57                         ` jdow
2018-06-30  1:31                           ` Michael Schmitz
2018-06-30  3:56                             ` jdow
2018-06-30  5:26                               ` Michael Schmitz
2018-06-30  6:47                                 ` jdow
2018-06-30  9:07                                   ` Martin Steigerwald
2018-06-30  9:39                                     ` jdow
2018-06-30  8:48                                 ` Martin Steigerwald
2018-06-30  9:28                                   ` jdow
2018-06-30  7:49                               ` Martin Steigerwald
2018-06-30  9:36                                 ` jdow
2018-07-01  2:43                                 ` Michael Schmitz
2018-07-01  4:36                                   ` jdow
2018-07-01 12:26                                   ` Martin Steigerwald
2018-06-29 12:44                 ` Andreas Schwab
2018-06-30 21:21                   ` Geert Uytterhoeven
2018-06-29 21:10                 ` Martin Steigerwald
2018-06-28  9:20           ` jdow
2018-06-28  9:29             ` Geert Uytterhoeven
2018-06-29  8:58           ` Michael Schmitz
2018-06-29  9:10             ` Geert Uytterhoeven
2018-06-29  9:19               ` Michael Schmitz
2018-06-28  7:28         ` Martin Steigerwald
2018-06-28  7:39           ` Geert Uytterhoeven
2018-06-28  9:34             ` jdow
2018-06-28  3:49   ` jdow
2018-06-27 13:30 ` Geert Uytterhoeven
2018-06-27 20:43   ` Michael Schmitz
2018-06-28  3:45   ` jdow
2018-06-29  9:12   ` Michael Schmitz
2018-06-30 21:10     ` Geert Uytterhoeven
2018-06-30 21:26       ` Michael Schmitz
2018-07-02  5:29 ` [PATCH] block: fix Amiga partition support for disks >= 1 TB Michael Schmitz
2018-07-02  6:38   ` Kars de Jong
2018-07-02 22:34     ` Michael Schmitz
2018-07-02  8:29   ` Geert Uytterhoeven
2018-07-02 23:58     ` Michael Schmitz
2018-07-03  7:22       ` Geert Uytterhoeven
2018-07-03  8:15         ` Michael Schmitz
2018-07-03 10:02         ` jdow
2018-07-02 19:36   ` Martin Steigerwald
2018-07-02 19:39     ` Martin Steigerwald
2018-07-03  7:19   ` [PATCH v2] " Michael Schmitz
2018-07-03 19:39   ` [PATCH v3] " Michael Schmitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a0974de4-da1f-3991-8d44-4108a81a0014@earthlink.net \
    --to=jdow@earthlink.net \
    --cc=axboe@kernel.dk \
    --cc=geert@linux-m68k.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=martin@lichtvoll.de \
    --cc=schmitzmic@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.