From: Scott Bauer <scott.bauer@intel.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "keith.busch@intel.com" <keith.busch@intel.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"hch@infradead.org" <hch@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"axboe@fb.com" <axboe@fb.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"jonathan.derrick@intel.com" <jonathan.derrick@intel.com>
Subject: Re: Sed-opal fixups
Date: Thu, 9 Feb 2017 10:45:27 -0700 [thread overview]
Message-ID: <20170209174526.GA5200@sbauer-Z170X-UD5> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB0281B85@AcuExch.aculab.com>
On Thu, Feb 09, 2017 at 05:43:20PM +0000, David Laight wrote:
> From: Scott Bauer
> > Sent: 09 February 2017 17:20
> > It may be too late to change anyhting in the uapi header. When we
> > switched over to using IOC_SIZE I found a bug where I had switched
> > up a structure in one of the series from v4 to v5 but never changed
> > the structure in the IOW. The structure that was in there was to small
> > so when we kzalloc on it we don't request enough space. It worked before
> > because we were using the cmd strictly as a command #, not using the IOC
> > and friends.
> >
> > If it's too late to modify that IOW, I can work around it by reallocing
> > on the correct size for that command only. I verified the rest of the
> > commands and the structures are the same.
> >
> > Let me know what you think, please.
>
> Maybe define IOC_OPAL_ACTIVATE_LSP_OLD to the incorrect value and
> IOC_OPAL_ACTIVATE_LSP to the correct one.
> But that relies on any users specifying the correct structure.
> I wouldn't guarantee that.
I think I'm the only userspace user right now, this went in on monday,
so I can can change my tooling easily. I just wasnt sure if there was a
set time where the user ABI cannot be changed.
>
> At the top of the driver's ioctl path add:
> if (cmd == IOC_OPAL_ACTIVATE_LSP_OLD) cmd = IOC_OPAL_ACTIVATE_LSP;
>
I think it would have to be the other way around the correct sized one would
be IOC_OPAL_ACTIAVE_LSP_NEW so the check would be:
if (cmd == IOC_OPAL_ACTIVATE_LSP) cmd = IOC_OPAL_ACTIVATE_LSP_NEW. If we're
allowed to change it (the bad sized one) from LSP to LSP_OLD then we should
just change the structure. If we have to leave it we need to introduce a _NEW
with the correct size.
> For some code I added a userspace wrapper on ioctl() to check the
> size of the supplied arg matched that required by the 'cmd'.
> I've also done the same in the kernel.
> (all as compile time checks).
>
> David
>
>
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
WARNING: multiple messages have this Message-ID (diff)
From: scott.bauer@intel.com (Scott Bauer)
Subject: Sed-opal fixups
Date: Thu, 9 Feb 2017 10:45:27 -0700 [thread overview]
Message-ID: <20170209174526.GA5200@sbauer-Z170X-UD5> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB0281B85@AcuExch.aculab.com>
On Thu, Feb 09, 2017@05:43:20PM +0000, David Laight wrote:
> From: Scott Bauer
> > Sent: 09 February 2017 17:20
> > It may be too late to change anyhting in the uapi header. When we
> > switched over to using IOC_SIZE I found a bug where I had switched
> > up a structure in one of the series from v4 to v5 but never changed
> > the structure in the IOW. The structure that was in there was to small
> > so when we kzalloc on it we don't request enough space. It worked before
> > because we were using the cmd strictly as a command #, not using the IOC
> > and friends.
> >
> > If it's too late to modify that IOW, I can work around it by reallocing
> > on the correct size for that command only. I verified the rest of the
> > commands and the structures are the same.
> >
> > Let me know what you think, please.
>
> Maybe define IOC_OPAL_ACTIVATE_LSP_OLD to the incorrect value and
> IOC_OPAL_ACTIVATE_LSP to the correct one.
> But that relies on any users specifying the correct structure.
> I wouldn't guarantee that.
I think I'm the only userspace user right now, this went in on monday,
so I can can change my tooling easily. I just wasnt sure if there was a
set time where the user ABI cannot be changed.
>
> At the top of the driver's ioctl path add:
> if (cmd == IOC_OPAL_ACTIVATE_LSP_OLD) cmd = IOC_OPAL_ACTIVATE_LSP;
>
I think it would have to be the other way around the correct sized one would
be IOC_OPAL_ACTIAVE_LSP_NEW so the check would be:
if (cmd == IOC_OPAL_ACTIVATE_LSP) cmd = IOC_OPAL_ACTIVATE_LSP_NEW. If we're
allowed to change it (the bad sized one) from LSP to LSP_OLD then we should
just change the structure. If we have to leave it we need to introduce a _NEW
with the correct size.
> For some code I added a userspace wrapper on ioctl() to check the
> size of the supplied arg matched that required by the 'cmd'.
> I've also done the same in the kernel.
> (all as compile time checks).
>
> David
>
>
next prev parent reply other threads:[~2017-02-09 17:45 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-09 17:19 Sed-opal fixups Scott Bauer
2017-02-09 17:19 ` Scott Bauer
2017-02-09 17:20 ` [PATCH V3 1/2] uapi: sed-opal fix IOW for activate lsp to use correct struct Scott Bauer
2017-02-09 17:20 ` Scott Bauer
2017-02-09 17:20 ` [PATCH V3 2/2] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN Scott Bauer
2017-02-09 17:20 ` Scott Bauer
2017-02-09 19:51 ` Rafael Antognolli
2017-02-09 19:51 ` Rafael Antognolli
2017-02-10 7:45 ` Johannes Thumshirn
2017-02-10 7:45 ` Johannes Thumshirn
2017-02-10 10:28 ` David Laight
2017-02-10 10:28 ` David Laight
2017-02-10 11:00 ` Arnd Bergmann
2017-02-10 11:00 ` Arnd Bergmann
2017-02-10 8:01 ` Arnd Bergmann
2017-02-10 8:01 ` Arnd Bergmann
2017-02-10 15:57 ` Scott Bauer
2017-02-10 15:57 ` Scott Bauer
2017-02-09 17:43 ` Sed-opal fixups David Laight
2017-02-09 17:43 ` David Laight
2017-02-09 17:45 ` Scott Bauer [this message]
2017-02-09 17:45 ` Scott Bauer
2017-02-09 18:24 ` Jens Axboe
2017-02-09 18:24 ` Jens Axboe
2017-02-09 20:01 ` Scott Bauer
2017-02-09 20:01 ` Scott Bauer
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=20170209174526.GA5200@sbauer-Z170X-UD5 \
--to=scott.bauer@intel.com \
--cc=David.Laight@ACULAB.COM \
--cc=arnd@arndb.de \
--cc=axboe@fb.com \
--cc=hch@infradead.org \
--cc=jonathan.derrick@intel.com \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
/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.