On Wed, Apr 20, 2022 at 12:41:53PM -0700, Eric Biggers wrote:
> On Wed, Apr 20, 2022 at 08:47:45AM +0200, Christoph Hellwig wrote:
> > Once the blk_crypto_profile is exposed in sysfs it needs to stay alive
> > as long as sysfs accesses are possibly pending. Ensure that by removing
> > the blk_crypto_kobj wrapper and just embedding the kobject into the
> > actual blk_crypto_profile. This requires the blk_crypto_profile
> > structure to be dynamically allocated, which in turn requires a private
> > data pointer for driver use.
> >
> > Fixes: 20f01f163203 ("blk-crypto: show crypto capabilities in sysfs")
> > Signed-off-by: Christoph Hellwig <hch@xxxxxx>
>
> Can you elaborate on what you think the actual problem is here? The lifetime of
> the blk_crypto_profile matches that of the host controller kobject, and I
> thought that it is not destroyed until after higher-level objects such as
> gendisks and request_queues are destroyed. Similar assumptions are made by the
> queue kobject, which assumes it is safe to access the gendisk, and by the
> independent_access_ranges kobject which assumes it is safe to access the queue.
>
> I suppose this wouldn't have worked with the original sysfs design where opening
> a file in sysfs actually got a refcount to the kobject. But that's long gone,
> having been changed in Linux v2.6.23 (https://lwn.net/Articles/229774).
>
> Note that commit 20f01f163203 which added this code got an "all looks good" from
> Greg KH (https://lore.kernel.org/r/YaH1CmHClx5WvDWD@xxxxxxxxx). I'd have hoped
> that he would've noticed if there was a major problem with how kobjects are used
> here! Greg, would you mind taking a look at this part again?
I do not know the model for the block devices and queues and all of that
well at all. My first glance this seemed sane, but if the lifetime
rules are not normal in any way, I do not know. I defer to Christoph
for all of this, he knows it way better than I do.
thanks,
greg k-h
