[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200227181411.GB877@sol.localdomain>
Date: Thu, 27 Feb 2020 10:14:11 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Satya Tangirala <satyat@...gle.com>, linux-block@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-fscrypt@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net, linux-ext4@...r.kernel.org,
Barani Muthukumaran <bmuthuku@....qualcomm.com>,
Kuohong Wang <kuohong.wang@...iatek.com>,
Kim Boojin <boojin.kim@...sung.com>
Subject: Re: [PATCH v7 1/9] block: Keyslot Manager for Inline Encryption
On Fri, Feb 21, 2020 at 09:31:18AM -0800, Christoph Hellwig wrote:
> On Fri, Feb 21, 2020 at 09:04:34AM -0800, Christoph Hellwig wrote:
> > Given that blk_ksm_get_slot_for_key returns a signed keyslot that
> > can return errors, and the only callers stores it in a signed variable
> > I think this function should take a signed slot as well, and the check
> > for a non-negative slot should be moved here from the only caller.
>
> Actually looking over the code again I think it might be better to
> return only the error code (and that might actually be a blk_status_t),
> and then use an argument to return a pointer to the actual struct
> keyslot. That gives us much easier to understand code and better
> type safety.
That doesn't make sense because the caller only cares about the keyslot number,
not the 'struct keyslot'. The 'struct keyslot' is internal to
keyslot-manager.c, as it only contains keyslot management information.
Your earlier suggestion of making blk_ksm_put_slot() be a no-op on a negative
keyslot number sounds fine though.
- Eric
Powered by blists - more mailing lists