From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 53C90C433F5 for ; Thu, 21 Apr 2022 14:25:56 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-277-M9syiGmlP0mz2B7EwEg_7w-1; Thu, 21 Apr 2022 10:25:51 -0400 X-MC-Unique: M9syiGmlP0mz2B7EwEg_7w-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0F26A3833FE8; Thu, 21 Apr 2022 14:25:50 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2200C1468940; Thu, 21 Apr 2022 14:25:47 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 361BE1949763; Thu, 21 Apr 2022 14:25:44 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 8ED9619451EF for ; Thu, 21 Apr 2022 14:25:43 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 44585413707; Thu, 21 Apr 2022 14:25:43 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast04.extmail.prod.ext.rdu2.redhat.com [10.11.55.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3FDC4572326 for ; Thu, 21 Apr 2022 14:25:43 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 266871014A60 for ; Thu, 21 Apr 2022 14:25:43 +0000 (UTC) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-126-WF_GNtZyPq2PduQI841Kig-1; Thu, 21 Apr 2022 10:25:40 -0400 X-MC-Unique: WF_GNtZyPq2PduQI841Kig-1 Received: by verein.lst.de (Postfix, from userid 2407) id 9CB7B68B05; Thu, 21 Apr 2022 16:25:35 +0200 (CEST) Date: Thu, 21 Apr 2022 16:25:35 +0200 From: Christoph Hellwig To: Eric Biggers Message-ID: <20220421142535.GA21025@lst.de> References: <20220420064745.1119823-1-hch@lst.de> <20220420064745.1119823-3-hch@lst.de> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 Subject: Re: [dm-devel] [PATCH 2/2] blk-crypto: fix the blk_crypto_profile liftime X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jens Axboe , Ulf Hansson , linux-scsi@vger.kernel.org, Greg Kroah-Hartman , Mike Snitzer , Adrian Hunter , Ritesh Harjani , linux-block@vger.kernel.org, Avri Altman , dm-devel@redhat.com, Alim Akhtar , linux-mmc@vger.kernel.org, Christoph Hellwig , Asutosh Das Errors-To: dm-devel-bounces@redhat.com Sender: "dm-devel" X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gV2VkLCBBcHIgMjAsIDIwMjIgYXQgMTI6NDE6NTNQTSAtMDcwMCwgRXJpYyBCaWdnZXJzIHdy b3RlOgo+IENhbiB5b3UgZWxhYm9yYXRlIG9uIHdoYXQgeW91IHRoaW5rIHRoZSBhY3R1YWwgcHJv YmxlbSBpcyBoZXJlPyAgVGhlIGxpZmV0aW1lIG9mCj4gdGhlIGJsa19jcnlwdG9fcHJvZmlsZSBt YXRjaGVzIHRoYXQgb2YgdGhlIGhvc3QgY29udHJvbGxlciBrb2JqZWN0LCBhbmQgSQo+IHRob3Vn aHQgdGhhdCBpdCBpcyBub3QgZGVzdHJveWVkIHVudGlsIGFmdGVyIGhpZ2hlci1sZXZlbCBvYmpl Y3RzIHN1Y2ggYXMKPiBnZW5kaXNrcyBhbmQgcmVxdWVzdF9xdWV1ZXMgYXJlIGRlc3Ryb3llZC4K CkkgZG9uJ3QgdGhpbmsgYWxsIGRyaXZlciBhdXRob3JzIGFncmVlIHdpdGggdGhhdCBhc3N1bXB0 aW9uIChhbmQgaXQgaXNuJ3QKZG9jdW1lbnRlZCBhbnl3aGVyZSkuIAoKVGhlIG1vc3QgdHJpdmlh bCBjYXNlIGlzIGRldmljZSBtYXBwZXIsIHdoZXJlIHRoZSBjcnlwdG8gcHJvZtGWbGUgaXMgZnJl ZWQKYmVmb3JlIHB1dHRpbmcgdGhlIGdlbmRpc2sgcmVmZXJlbmNlIGFjcXVpcmVkIGJ5IGJsa19h bGxvY19kaXNrLiAgU28KYW55b25lIHdobyBvcGVuZWQgdGhlIHN5c2ZzIGZpbGUgYXQgc29tZSBw b2ludCBiZWZvcmUgdGhlIGRlbGV0ZSBjYW4Kc3RpbGwgaGF2ZSBpdCBvcGVuIGFuZCB0cml2aWFs bCBhY2Nlc3MgZnJlZWQgbWVtb3J5IHdoZW4gdGhlbiBkb2luZwphIHJlYWQgb24gaXQgYWZ0ZXIg dGhlIGRtIHRhYmxlIGlzIGZyZWVkLgoKRm9yIFVGUyB0aGluZ3Mgc2VlbSB0byB3b3JrIG91dCBv ayBiZWNhdXNlIHRoZSB1ZnNfaGJhIGlzIHBhcnQgb2YKdGhlIFNjc2lfSG9zdCwgd2hpY2ggaXMg dGhlIHBhcmVudCBkZXZpY2Ugb2YgdGhlIGdlbmRpc2suCgo+IFNpbWlsYXIgYXNzdW1wdGlvbnMg YXJlIG1hZGUgYnkgdGhlCj4gcXVldWUga29iamVjdCwgd2hpY2ggYXNzdW1lcyBpdCBpcyBzYWZl IHRvIGFjY2VzcyB0aGUgZ2VuZGlzaywgYW5kIGJ5IHRoZQo+IGluZGVwZW5kZW50X2FjY2Vzc19y YW5nZXMga29iamVjdCB3aGljaCBhc3N1bWVzIGl0IGlzIHNhZmUgdG8gYWNjZXNzIHRoZSBxdWV1 ZS4KClllcywgZXZlcnkgcXVldWUvIG9iamVjdCB0aGF0IHJlZmVyZW5jZXMgdGhlIGdlbmRpc2sg aGFzIGEgcHJvYmxlbSBJIHRoaW5rLgpJJ3ZlIGJlZW4gd2FkaW5nIHRocm91Z2ggdGhpcyBjb2Rl IGFuZCB0cnlpbmcgdG8gZml4IGl0LCB3aGljaCBtYWRlIG1lCm5vdGljZSB0aGlzIGNvZGUuCgo+ IEluIGFueSBjYXNlLCB0aGlzIHByb3Bvc2FsIGlzIG5vdCBjb3JyZWN0IHNpbmNlIGl0IGlzIGFz c3VtaW5nIHRoYXQgZWFjaAo+IGJsa19jcnlwdG9fcHJvZmlsZSBpcyByZWZlcmVuY2VkIGJ5IG9u bHkgb25lIHJlcXVlc3RfcXVldWUsIHdoaWNoIGlzIG5vdAo+IG5lY2Vzc2FyaWx5IHRoZSBjYXNl IHNpbmNlIGEgaG9zdCBjb250cm9sbGVyIGNhbiBoYXZlIG11bHRpcGxlIGRpc2tzLgo+IFRoZSBz YW1lIGtvYmplY3QgY2FuJ3QgYmUgYWRkZWQgdG8gbXVsdGlwbGUgcGxhY2VzIGluIHRoZSBoaWVy YXJjaHkuCgpJbmRlZWQuCgo+IElmIHdlIGRpZCBuZWVkIHRvIGRvIHNvbWV0aGluZyBkaWZmZXJl bnRseSBoZXJlLCBJIHRoaW5rIHdlJ2QgZWl0aGVyIG5lZWQgdG8gcHV0Cj4gdGhlIGJsa19jcnlw dG9fcHJvZmlsZSBrb2JqZWN0IHVuZGVyIHRoZSBob3N0IGNvbnRyb2xsZXIgb25lIGFuZCBsaW5r IHRvIGl0IGZyb20KPiB0aGUgcXVldWUgZGlyZWN0b3JpZXMgKHdoaWNoIEkgbWVudGlvbmVkIGlu IGNvbW1pdCAyMGYwMWYxNjMyMDMgYXMgYW4KPiBhbHRlcm5hdGl2ZSBjb25zaWRlcmVkKSwgb3Ig ZHVwbGljYXRlIHRoZSBjcnlwdG8gY2FwYWJpbGl0aWVzIGluIGVhY2gKPiByZXF1ZXN0X3F1ZXVl IGFuZCBvbmx5IHNoYXJlIHRoZSBhY3R1YWwga2V5c2xvdCBtYW5hZ2VtZW50IGRhdGEgc3RydWN0 dXJlcy4KCkRvIHdlIGV2ZW4gbmVlZCB0aGUgbGluayBpbnN0ZWFkIG9mIGxldHRpbmcgdGhlIHVz ZXIgd2FsayBkb3duIHRoZQpkaXJlY3RvcnkgaGllcmFjaHk/ICBCdXQgeWVzLCBoYXZpbmcgdGhl IHN5c2ZzIGF0dHJpYnV0ZXMgb24gdGhlCmFjdHVhbCBvYmplY3QgaXMgYSBtdWNoIGJldHRlciBp ZGVhLgoKPiAKPiAtIEVyaWMKLS0tZW5kIHF1b3RlZCB0ZXh0LS0tCgotLQpkbS1kZXZlbCBtYWls aW5nIGxpc3QKZG0tZGV2ZWxAcmVkaGF0LmNvbQpodHRwczovL2xpc3RtYW4ucmVkaGF0LmNvbS9t YWlsbWFuL2xpc3RpbmZvL2RtLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D39E1C433F5 for ; Thu, 21 Apr 2022 14:25:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1389195AbiDUO2b (ORCPT ); Thu, 21 Apr 2022 10:28:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1388932AbiDUO2a (ORCPT ); Thu, 21 Apr 2022 10:28:30 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46AE911A3D; Thu, 21 Apr 2022 07:25:41 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 9CB7B68B05; Thu, 21 Apr 2022 16:25:35 +0200 (CEST) Date: Thu, 21 Apr 2022 16:25:35 +0200 From: Christoph Hellwig To: Eric Biggers Cc: Christoph Hellwig , Greg Kroah-Hartman , Jens Axboe , Mike Snitzer , Ulf Hansson , Adrian Hunter , Ritesh Harjani , Asutosh Das , Alim Akhtar , Avri Altman , dm-devel@redhat.com, linux-block@vger.kernel.org, linux-mmc@vger.kernel.org, linux-scsi@vger.kernel.org Subject: Re: [PATCH 2/2] blk-crypto: fix the blk_crypto_profile liftime Message-ID: <20220421142535.GA21025@lst.de> References: <20220420064745.1119823-1-hch@lst.de> <20220420064745.1119823-3-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Wed, Apr 20, 2022 at 12:41:53PM -0700, Eric Biggers wrote: > 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. I don't think all driver authors agree with that assumption (and it isn't documented anywhere). The most trivial case is device mapper, where the crypto profіle is freed before putting the gendisk reference acquired by blk_alloc_disk. So anyone who opened the sysfs file at some point before the delete can still have it open and triviall access freed memory when then doing a read on it after the dm table is freed. For UFS things seem to work out ok because the ufs_hba is part of the Scsi_Host, which is the parent device of the gendisk. > 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. Yes, every queue/ object that references the gendisk has a problem I think. I've been wading through this code and trying to fix it, which made me notice this code. > In any case, this proposal is not correct since it is assuming that each > blk_crypto_profile is referenced by only one request_queue, which is not > necessarily the case since a host controller can have multiple disks. > The same kobject can't be added to multiple places in the hierarchy. Indeed. > If we did need to do something differently here, I think we'd either need to put > the blk_crypto_profile kobject under the host controller one and link to it from > the queue directories (which I mentioned in commit 20f01f163203 as an > alternative considered), or duplicate the crypto capabilities in each > request_queue and only share the actual keyslot management data structures. Do we even need the link instead of letting the user walk down the directory hierachy? But yes, having the sysfs attributes on the actual object is a much better idea. > > - Eric ---end quoted text---