From: David Kozub <zub@linux.fjfi.cvut.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>,
Jonathan Derrick <jonathan.derrick@intel.com>,
Scott Bauer <sbauer@plzdonthack.me>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
Jonas Rabenstein <jonas.rabenstein@studium.uni-erlangen.de>
Subject: Re: [PATCH v4 10/16] block: sed-opal: add ioctl for done-mark of shadow mbr
Date: Thu, 7 Feb 2019 23:56:48 +0100 (CET) [thread overview]
Message-ID: <alpine.LRH.2.21.1902072247060.29258@linux.fjfi.cvut.cz> (raw)
In-Reply-To: <20190204145244.GJ31132@infradead.org>
On Mon, 4 Feb 2019, Christoph Hellwig wrote:
> On Fri, Feb 01, 2019 at 09:50:17PM +0100, David Kozub wrote:
>> From: Jonas Rabenstein <jonas.rabenstein@studium.uni-erlangen.de>
>>
>> Enable users to mark the shadow mbr as done without completely
>> deactivating the shadow mbr feature. This may be useful on reboots,
>> when the power to the disk is not disconnected in between and the shadow
>> mbr stores the required boot files. Of course, this saves also the
>> (few) commands required to enable the feature if it is already enabled
>> and one only wants to mark the shadow mbr as done.
>>
>> Signed-off-by: Jonas Rabenstein <jonas.rabenstein@studium.uni-erlangen.de>
>> Reviewed-by: Scott Bauer <sbauer@plzdonthack.me>
>> ---
>> block/sed-opal.c | 33 +++++++++++++++++++++++++++++++--
>> include/linux/sed-opal.h | 1 +
>> include/uapi/linux/sed-opal.h | 1 +
>> 3 files changed, 33 insertions(+), 2 deletions(-)
>>
>> diff --git a/block/sed-opal.c b/block/sed-opal.c
>> index 4b0a63b9d7c9..e03838cfd31b 100644
>> --- a/block/sed-opal.c
>> +++ b/block/sed-opal.c
>> @@ -1996,13 +1996,39 @@ static int opal_erase_locking_range(struct opal_dev *dev,
>> static int opal_enable_disable_shadow_mbr(struct opal_dev *dev,
>> struct opal_mbr_data *opal_mbr)
>> {
>> + u8 token = opal_mbr->enable_disable == OPAL_MBR_ENABLE
>> + ? OPAL_TRUE : OPAL_FALSE;
>> const struct opal_step mbr_steps[] = {
>> { opal_discovery0, },
>> { start_admin1LSP_opal_session, &opal_mbr->key },
>> - { set_mbr_done, &opal_mbr->enable_disable },
>> + { set_mbr_done, &token },
>> { end_opal_session, },
>> { start_admin1LSP_opal_session, &opal_mbr->key },
>> - { set_mbr_enable_disable, &opal_mbr->enable_disable },
>> + { set_mbr_enable_disable, &token },
>> + { end_opal_session, },
>> + { NULL, }
>
> This seems to be a change of what we pass to set_mbr_done /
> set_mbr_enable_disable and not really related to the new functionality
> here, so it should be split into a separate patch.
>
> That being said if we really care about this translation between
> the two sets of constants, why not do it inside
> set_mbr_done and set_mbr_enable_disable?
Hi Christoph,
I agree, this should be split. Furthermore I think I found an issue here:
OPAL_MBR_ENABLE and OPAL_MBR_DISABLE are defined as follows:
enum opal_mbr {
OPAL_MBR_ENABLE = 0x0,
OPAL_MBR_DISABLE = 0x01,
};
... while OPAL_TRUE and OPAL_FALSE tokens are:
OPAL_TRUE = 0x01,
OPAL_FALSE = 0x00,
so in the current code in kernel, when the IOCTL input is directly passed
in place of the TRUE/FALSE tokens (in opal_enable_disable_shadow_mbr),
passing OPAL_MBR_ENABLE (0) to IOC_OPAL_ENABLE_DISABLE_MBR ends up being
interpreted as OPAL_FALSE (0) and passing OPAL_MBR_DISABLE (1) ended up
being interpreted as OPAL_TRUE (1). So the behavior is:
OPAL_MBR_ENABLE: set MBR enable to OPAL_FALSE and done to OPAL_FALSE
OPAL_MBR_DISABLE: set MBR enable to OPAL_TRUE and done to OPAL_TRUE
Am I missing something here? This seems wrong to me. And I think this
patch actually changes it by introducing:
+ u8 token = opal_mbr->enable_disable == OPAL_MBR_ENABLE
+ ? OPAL_TRUE : OPAL_FALSE;
which is essentially a negation (map 0 to 1 and 1 to 0).
I had a strange feeling of IOC_OPAL_ENABLE_DISABLE_MBR behaving
incorrectly when I first tried it. But when I checked later I was not able
to reproduce it - probably originally I tested without this patch.
With regard to the new IOC_OPAL_MBR_STATUS: I find the usage of
OPAL_MBR_ENABLE/DISABLE for this confusing: what should passing
OPAL_MBR_ENABLE do? Should it enable the shadow MBR? Or should it
enable the MBR-done flag? I think the implementation in this patch
interprets OPAL_MBR_ENABLE as 'set the "done" flag to true', thus hiding
the shadow MBR. But this is not obvious looking at the IOCTL name.
What if I introduced two new constants for this? OPAL_MBR_DONE and
OPAL_MBR_NOT_DONE? Maybe the IOCTL could be renamed too -
IOC_OPAL_MBR_DONE? Or is it only me who finds this confusing?
Best regards,
David
next prev parent reply other threads:[~2019-02-07 22:56 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-01 20:50 [PATCH v4 00/16] block: sed-opal: support shadow MBR done flag and write David Kozub
2019-02-01 20:50 ` [PATCH v4 01/16] block: sed-opal: fix typos and formatting David Kozub
2019-02-04 14:42 ` Christoph Hellwig
2019-02-04 20:28 ` David Kozub
2019-02-08 22:56 ` Derrick, Jonathan
2019-02-01 20:50 ` [PATCH v4 02/16] block: sed-opal: use correct macro for method length David Kozub
2019-02-04 14:43 ` Christoph Hellwig
2019-02-08 22:56 ` Derrick, Jonathan
2019-02-01 20:50 ` [PATCH v4 03/16] block: sed-opal: unify space check in add_token_* David Kozub
2019-02-04 14:44 ` Christoph Hellwig
2019-02-04 21:07 ` David Kozub
2019-02-04 21:09 ` Christoph Hellwig
2019-02-08 22:57 ` Derrick, Jonathan
2019-02-01 20:50 ` [PATCH v4 04/16] block: sed-opal: close parameter list in cmd_finalize David Kozub
2019-02-04 14:44 ` Christoph Hellwig
2019-02-08 22:57 ` Derrick, Jonathan
2019-02-01 20:50 ` [PATCH v4 05/16] block: sed-opal: unify cmd start David Kozub
2019-02-04 14:45 ` Christoph Hellwig
2019-02-08 22:57 ` Derrick, Jonathan
2019-02-01 20:50 ` [PATCH v4 06/16] block: sed-opal: unify error handling of responses David Kozub
2019-02-04 14:45 ` Christoph Hellwig
2019-02-01 20:50 ` [PATCH v4 07/16] block: sed-opal: reuse response_get_token to decrease code duplication David Kozub
2019-02-04 14:46 ` Christoph Hellwig
2019-02-08 22:57 ` Derrick, Jonathan
2019-02-01 20:50 ` [PATCH v4 08/16] block: sed-opal: print failed function address David Kozub
2019-02-04 14:46 ` Christoph Hellwig
2019-02-01 20:50 ` [PATCH v4 09/16] block: sed-opal: split generation of bytestring header and content David Kozub
2019-02-04 14:48 ` Christoph Hellwig
2019-02-08 22:58 ` Derrick, Jonathan
2019-02-01 20:50 ` [PATCH v4 10/16] block: sed-opal: add ioctl for done-mark of shadow mbr David Kozub
2019-02-04 14:52 ` Christoph Hellwig
2019-02-07 22:56 ` David Kozub [this message]
2019-02-08 0:44 ` Derrick, Jonathan
2019-02-08 1:37 ` Scott Bauer
2019-02-10 18:26 ` Scott Bauer
2019-02-10 20:25 ` David Kozub
2019-02-01 20:50 ` [PATCH v4 11/16] block: sed-opal: ioctl for writing to " David Kozub
2019-02-04 17:58 ` kbuild test robot
2019-02-08 22:58 ` Derrick, Jonathan
2019-02-01 20:50 ` [PATCH v4 12/16] block: sed-opal: unify retrieval of table columns David Kozub
2019-02-04 14:56 ` Christoph Hellwig
2019-02-08 22:58 ` Derrick, Jonathan
2019-02-01 20:50 ` [PATCH v4 13/16] block: sed-opal: check size of shadow mbr David Kozub
2019-02-08 22:58 ` Derrick, Jonathan
2019-02-10 20:05 ` David Kozub
2019-02-11 21:27 ` Derrick, Jonathan
2019-02-01 20:50 ` [PATCH v4 14/16] block: sed-opal: pass steps via argument rather than via opal_dev David Kozub
2019-02-04 14:57 ` Christoph Hellwig
2019-02-01 20:50 ` [PATCH v4 15/16] block: sed-opal: don't repeat opal_discovery0 in each steps array David Kozub
2019-02-04 15:01 ` Christoph Hellwig
2019-02-04 22:44 ` David Kozub
2019-02-08 22:59 ` Derrick, Jonathan
2019-02-10 17:46 ` David Kozub
2019-02-11 17:22 ` Derrick, Jonathan
2019-02-01 20:50 ` [PATCH v4 16/16] block: sed-opal: rename next to execute_steps David Kozub
2019-02-04 15:01 ` Christoph Hellwig
2019-02-08 22:59 ` Derrick, Jonathan
2019-02-04 8:55 ` David Kozub
2019-02-04 9:44 ` [PATCH v4 00/16] block: sed-opal: support shadow MBR done flag and write David Kozub
2019-02-04 15:04 ` Christoph Hellwig
2019-02-04 15:36 ` Scott Bauer
2019-02-04 15:44 ` Christoph Hellwig
2019-02-04 23:06 ` David Kozub
2019-02-05 6:57 ` Christoph Hellwig
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=alpine.LRH.2.21.1902072247060.29258@linux.fjfi.cvut.cz \
--to=zub@linux.fjfi.cvut.cz \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=jonas.rabenstein@studium.uni-erlangen.de \
--cc=jonathan.derrick@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sbauer@plzdonthack.me \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).