From: Martin Steigerwald <martin@lichtvoll.de>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Joanne Dow <jdow@earthlink.net>,
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: Wed, 27 Jun 2018 23:20:07 +0200 [thread overview]
Message-ID: <3488210.nMeMqUQulA@merkaba> (raw)
In-Reply-To: <CAOmrzkLZCE7jPHVP0Et7L7=8UAAG80v7gpYrKpZVJADQz6PeaA@mail.gmail.com>
Hi Michael.
Michael Schmitz - 27.06.18, 22:13:
> On Wed, Jun 27, 2018 at 8:24 PM, Martin Steigerwald=20
<martin@lichtvoll.de> wrote:
> > Thanks a lot again for your patch.
> >=20
> > schmitzmic@gmail.com - 27.06.18, 03:24:
> >> + if (start_sect > INT_MAX || nr_sects > INT_MAX
> >> + || (start_sect + nr_sects) > INT_MAX) {
> >> + pr_err("%s: Warning: RDB partition
> >> overflow!\n", + bdevname(state->bdev,
> >=20
> > I=B4d word this:
> >=20
> > Warning: RDB partition 32-bit overflow
> >=20
> > AmigaOS developers can do 64 bit math on a 32 bit operating system.
> > Just like Linux can.
>=20
> Yes, I realize that. I hadn't gone back through all the mails on the
> subject to find out what the exact requrements are on the AmigaOS
> side.
>=20
> Just trying to be as terse as possible to keep checkpatch happy :-(
>=20
> >> b));
> >> + pr_err("%s: start 0x%llX size 0x%llX\n",
> >> + bdevname(state->bdev, b),
> >> start_sect,
> >> + nr_sects);
> >> + pr_err("%s: partition incompatible with 32
> >> bit OS\n", + bdevname(state->bdev,
> >> b)); + }
> >=20
> > And as stated in my other reply to the patch:
> >=20
> > partition needs 64 bit disk device support in AmigaOS or AmigaOS
> > like
> > operating systems (NSD64, TD64 or SCSI direct)
>=20
> I'd probably leave it at 'disk needs 64 bit disk device support on
> native OS', and only print that warning once.
This is fine with me.
> Geert has raised another important point about 64 bt device support -
> all this is moot when the Linux kernel wasn't built with large block
> device support enabled (you'd get the same buggy behaviour as before
> the patch there).
>=20
> > see my other reply to the patch and my other mails in the
> > "Re: moving affs + RDB partition support to staging?" thread as to
> > why. And for references.
>=20
> Thanks for collating all the references. Please understand that I
> can't read all of that, and as a simple patch mechanic I won't even
> try to grasp all the subtleties of RDB (I don't even own an Amiga so I
> am quite unlikey to ever use this code path).
I understand that.
> But please also understand that for that reason, I take Joanne's
> advice about backwards compatibility very serious. My patch (actually
> Joanne's originally) changes kernel behaviour from what we consider
> broken (allowing 32 bit overflow in partition address calculations) to
> what we think is the right thing to do. But there might be someone
> out there who used the current behaviour to craft a RDB that aliows
> two separate sets of partitions to coexist on the same disk (one set
> visible to 32 bit disk drivers, before the 32 bit overflow mark, and
> a second set above that mark, visible only to 64 bit drivers.
> Silently changing our parser behaviour might cause said user to now
> trash data past the overflow mark.). This is a little contrived, and
> perhaps I am overcomplicating matters (again), but can't be ruled
> out.
>=20
> In the interest of least surprises, we have to fix the 32 bit overflow
> (so we can even detect that it would have happened), and give the
> user the chance to carefully consider whether to accept the new
> behaviour. That means refusing to make available any partition that
> would have been affected by such overflow.
That is acceptable for me as I told before. Either mount or refuse to=20
mount, but do not overflow and mount nonetheless :)
Mind you, I am not using my Amiga machines either at the moment. And I=20
repurposed the 2 TB disk years ago.=20
=20
> The user has then all options available - force old behaviour by using
> an older kernel, override the parser to force new behaviour (which we
> all assume is correct), or leave the disk well alone.
Sure.
I would not name the kernel option "eat_my_rdb", but use a less=20
dramatizing name.
Maybe just: "allow_64bit_rdb" or something like that.
How does the user come to know about this kernel option? Will you print=20
its name in kernel log?
Thanks,
=2D-=20
Martin
next prev parent reply other threads:[~2018-06-27 21:20 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 [this message]
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
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=3488210.nMeMqUQulA@merkaba \
--to=martin@lichtvoll.de \
--cc=axboe@kernel.dk \
--cc=geert@linux-m68k.org \
--cc=jdow@earthlink.net \
--cc=linux-block@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--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.