Re: [PATCH v7 1/9] block: Keyslot Manager for Inline Encryption
From: Satya Tangirala <hidden>
Date: 2020-02-27 21:25:20
Also in:
linux-ext4, linux-f2fs-devel, linux-fscrypt, linux-fsdevel, linux-scsi
On Thu, Feb 27, 2020 at 10:14:11AM -0800, Eric Biggers wrote:
On Fri, Feb 21, 2020 at 09:31:18AM -0800, Christoph Hellwig wrote:quoted
On Fri, Feb 21, 2020 at 09:04:34AM -0800, Christoph Hellwig wrote:quoted
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.
I think it does make some sense at least to make the keyslot type opaque to most of the system other than the driver itself (the driver will now have to call a function like blk_ksm_slot_idx_for_keyslot to actually get a keyslot number at the end of the day). Also this way, the keyslot manager can verify that the keyslot passed to blk_ksm_put_slot is actually part of that keyslot manager (and that somebody isn't releasing a slot number that was actually acquired from a different keyslot manager). I don't think it's much benefit or loss either way, but I already switched to passing pointers to struct keyslot around instead of ints, so I'll keep it that way unless you strongly feel that using ints in this case is better than struct keyslot *.
Your earlier suggestion of making blk_ksm_put_slot() be a no-op on a negative keyslot number sounds fine though. - Eric