Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp4386993rdb; Mon, 11 Dec 2023 19:03:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IECY+gQFwFtd5H3407Go950MveaJbnXa28/rZ78nOQ/O5sU1MNpZw9Z/BXLYCBnwOFPvGIL X-Received: by 2002:a17:902:728e:b0:1d0:94f8:ab1b with SMTP id d14-20020a170902728e00b001d094f8ab1bmr2670733pll.122.1702350200894; Mon, 11 Dec 2023 19:03:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702350200; cv=none; d=google.com; s=arc-20160816; b=EdMX0/N3z3P2aD7Md0VTUyi9mu86saR4/bcaKi7JytwZ3+UQ4nCXhDqy0+gqvtX2rQ RdMnhKB911nfFgLnP5sYXIoR2w6vDDyhbbb1EvBE27wqYVEX5zGs9Tr8KvIaO6jwFO+d DaH1K0ojFb98gVOT/yHl0NNfIakXVgoTasqb2NfdXPnB85BTv4rvC8c9AxC67ql2N33K OrxTMR7j/0FXk9pvtIq/gWgxNHi3/k0HfPFEJY7qIar3YUzJhpKHUq7fBRAZ9Elj4F5p H4dB2gkdncRKAPAzHT8QSyidhQneRwbM8826j3z0eBgWACxtH0LmpmLcHgfC1p1RPmF4 7cDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=GG/MIHsR3Tx1Gpviuxv7DcEJwvPTHVx8rqa10lI0ZcQ=; fh=RVfVH3jGGhsX6AdM7MAnsV7p6Ep0KYuQm/ty7F3kmGM=; b=wS3Yx50TEDHR1IaJj7vkDtIPpdhzN3n2fbWAJichQ/wfQjgGQkkzwmsbi0CH5yOh+7 /zqiZ3HKHXd8ciz6WA5iEmY3v1gyu2aXraedvwoCPmg4FkEhLpT7uET9JOcgWqcIBkqy TDU78gm764nz7eYOz0XUfGYt4dTsWQ13uGFbOBmYeVXEnTuX3PgmBAhr+EfnI3H0qd1g HpsQFnbfmyFSE9bTGW+yc50obm08c4qEeYj8MGw/k3RbBpk/FVSRHAWOrV61R6mt0eFX Aqdbkz0fpktOhLfae3a9nEOMwcm2xbWQcovgpjcUaCfbyvid4Kpv/SXbGTAxGwRnfTdc 1brA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hcOPdWev; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id p18-20020a170902ead200b001d051143067si6983693pld.317.2023.12.11.19.03.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Dec 2023 19:03:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hcOPdWev; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id C718080A6BC6; Mon, 11 Dec 2023 19:03:18 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345698AbjLLDDB (ORCPT + 99 others); Mon, 11 Dec 2023 22:03:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229587AbjLLDDA (ORCPT ); Mon, 11 Dec 2023 22:03:00 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBD9C9C for ; Mon, 11 Dec 2023 19:03:06 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9F68C433C7; Tue, 12 Dec 2023 03:03:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702350186; bh=V6aKJvuenIIPeYtYC/2j963aubdSI2b0OSCD3ucQPBQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hcOPdWevTHR2NUgEZZhGgvvqpu55ol3BkhpdrzGG8CV2x/D4T7pc0qj+dbicbmv2H vLbeHrFmJpv0oXlqhVynTTAoIBxZ0ySpvi6iBZjbxnSi2zodAwqHxXK32t7tTSRFkZ m/b4HDwsWJMH5nd/qRhdYByw8u7LDzJ8AaPlDuP5GW5Q8Cz6J9BpB3p7mk/rzMZVFm OSyR+HTdc9ejXom2U6xJTHNDsVhBFHkF7i3Upk1Qyvebz/CdPOqjYHCqC0m4KFk6BT 1LVXuuFkiaKHRQwPvakKQd4oW6dZV+AQ6M9CtH7xhHkWWMRkZL7d5V2vynsX5Bk+X6 cMoPE+6WfyVfA== Date: Mon, 11 Dec 2023 19:03:04 -0800 From: Eric Biggers To: David Howells Cc: Luis Henriques , Jarkko Sakkinen , keyrings@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] keys: flush work when accessing /proc/key-users Message-ID: <20231212030304.GA39443@sol.localdomain> References: <20231207024323.GA1994@sol.localdomain> <20231206145744.17277-1-lhenriques@suse.de> <498294.1701878642@warthog.procyon.org.uk> <87bkb3z047.fsf@suse.de> <2744563.1702303367@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2744563.1702303367@warthog.procyon.org.uk> X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Mon, 11 Dec 2023 19:03:18 -0800 (PST) On Mon, Dec 11, 2023 at 02:02:47PM +0000, David Howells wrote: > Eric Biggers wrote: > > > If there was a function that fully and synchronously releases a key's quota, > > fs/crypto/ could call it before unlinking the key. key_payload_reserve(key, > > 0) almost does the trick, but it would release the key's bytes, not the key > > itself. > > Umm... The point of the quota is that the key is occupying unswappable kernel > memory (partly true in the case of big_key) and we need to limit that. > Further, the key is not released until it is unlinked. Well, fs/crypto/ no longer uses the keyrings subsystem for the actual keys, as that was far too broken. It just ties into the quota now. So what's needed is a way to release quota synchronously. That might just mean not using the keyrings subsystem at all anymore. > Do we need faster disposal of keys? Perhaps keeping a list of keys that need > destroying rather than scanning the entire key set for them. We still need to > scan non-destroyed keyrings, though, to find the pointers to defunct keys > unless I have some sort of backpointer list. If it's still asynchronous, that doesn't solve the problem. - Eric