Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp88327img; Tue, 19 Mar 2019 18:38:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqwqLnuUASbfGmWeNLFvMn5TPnOhBdSE/aOzFhZSbqQ87oYeRAsRYYsJ77DgEo09F4did41f X-Received: by 2002:a62:e411:: with SMTP id r17mr17227349pfh.127.1553045917026; Tue, 19 Mar 2019 18:38:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553045917; cv=none; d=google.com; s=arc-20160816; b=ZY6q16GCgF6NS9tD81rzBz0b1SnRKJ8xj1KBJBj6T2xdhoEX3ELaHyRtPVD8rxkYY2 do9jUhdsJSIvab77Y/3awPm1AXdoKDmErluJ6nokLBb8OCcEPsgFCS2uNdrjMkFm0GxT wkVf37i3VeGnzNV8Aq0Cf6NeggfG8X24AXTtSrU+8YquffAYlvHWQchDVWUBWim4sqNN WqngMdGht47LRe9YfaJXzVqZyqr6h35qCCx6GXHyIaDDiRH/pRQayeph41JnAoWFTtgv bSL8s/Z0hnKBWmHARLMlt4DYpuyXsGcTIfrYQt6NdGx2nmmDFPEtNwF2mwKuVfq8zvAH PbcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=uQvOfL9VyCeC/ulxOcrUXP8emythXo3occMiKkN1eL8=; b=MVYTmDExxrS78WRRlty0vOTYq90nVyowrok5+co98twARE6lmyndtMMdXe7GVYUSrT OMQfFgMsV1jPeuoUQw3pccAKEw7TSnJMT90/eisXpQ9IsMu1Id9YTsrf2NtjGlwhqAHa AjUXxTyWMSRiIHtB3pq90a4hBkVhTti43z1wwkZOKaX/4jEpVk+QppqN38xO518PpdJf W2GzeOctY8hKhnqAXNqrU4fo3yeDMgYn9yKAxgu5cBHZkJ1i0kwbGKWH9ZBEVHR8MxUB N0p6p9GwzQfilaYDQXGpuY6sIda4g1hfyz5/NwBnSoW1cv718qDW3yuwcqlSmQaZZfrQ qFSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=jWNy2+OL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id go16si552906plb.132.2019.03.19.18.38.21; Tue, 19 Mar 2019 18:38:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=jWNy2+OL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727247AbfCTBhm (ORCPT + 99 others); Tue, 19 Mar 2019 21:37:42 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:33994 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726884AbfCTBhl (ORCPT ); Tue, 19 Mar 2019 21:37:41 -0400 Received: by mail-oi1-f194.google.com with SMTP id u12so548510oiv.1 for ; Tue, 19 Mar 2019 18:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uQvOfL9VyCeC/ulxOcrUXP8emythXo3occMiKkN1eL8=; b=jWNy2+OLXCqPThI08aYWVzcOtoczw4Z0AtZocBSl7v/f/G8kMKQnnpYy9Kht3UdoUZ s0/dYjZYi6yiml6Ul5WkY/NlJKVSlaY4eeuNZ6La43gbYhcwqVrn43Rdh6IDcg44bhlI GlcZSp+3qUoXJir2RWriOuQXSJZELwNxZT6gA8TLHbgXxzwLI34qH3+d9RdZPLZu1GnU nHn4Fv2TRBdvC/Iz08XOOAKKOuwXrdToi6C1qhvZ4ynnwqZlCCvMPLHDZ0I8/GrCBBQy RanBS3C4mBS5MxUxn2ZN7kfaKBErWBYLYtsN0rL7wqf+Iab55OvtgEQzYtz8DzriCCS1 OalA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uQvOfL9VyCeC/ulxOcrUXP8emythXo3occMiKkN1eL8=; b=PduJInDIwbohvyXYk3WfZc3TBNj4daodUTGNmqTLJdCL8oXl9MKQ4zMJlnl33aUugY pYxvcPi03HasQRDFJD6ja5VhrM7U2BHhMji6H9bYR7mx93m9EHmh9BPI81v80xeK5hVv aL9aSerqdrKnamq/c1BJcHIbjs9fclBK6QM6zfzEjp0r7NadOJW4mdvxrRjsJhrZFfKI VGc1/mHp1ILz3GM2nuad9VFEHvdaZme5aP85g6Z/3BUtDkbNg28C2Q7wx6PPCf3OGhJ/ 5QofOCmhL0+zHp8WwMfGZhJwFjDh3vgQ/PeZi8rKet344BeCHY+1ot9klzMfpyI7AdRB I7LA== X-Gm-Message-State: APjAAAUoF7yp982brVV/iHQ4gVIV41Csaq4gT+tclJsvMaq519X+Yp6v sk/Ak6Qo7XzNSqGaoizMHPuKlGY6SqOTHpNRxj1m2vL8gLU= X-Received: by 2002:aca:df57:: with SMTP id w84mr3578973oig.105.1553045860543; Tue, 19 Mar 2019 18:37:40 -0700 (PDT) MIME-Version: 1.0 References: <155297557534.2276575.16264199708584900090.stgit@dwillia2-desk3.amr.corp.intel.com> <155297558570.2276575.11731393787282486177.stgit@dwillia2-desk3.amr.corp.intel.com> <1553040398.4899.149.camel@linux.ibm.com> <1553044252.4899.165.camel@linux.ibm.com> In-Reply-To: From: Dan Williams Date: Tue, 19 Mar 2019 18:37:29 -0700 Message-ID: Subject: Re: [PATCH 2/6] security/keys/encrypted: Clean up request_trusted_key() To: Mimi Zohar Cc: keyrings@vger.kernel.org, James Bottomley , David Howells , Vishal L Verma , linux-nvdimm , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 19, 2019 at 6:34 PM Dan Williams wrote: > > On Tue, Mar 19, 2019 at 6:11 PM Mimi Zohar wrote: > > > > On Tue, 2019-03-19 at 17:20 -0700, Dan Williams wrote: > > > On Tue, Mar 19, 2019 at 5:07 PM Mimi Zohar wrote: > > > > On Mon, 2019-03-18 at 23:06 -0700, Dan Williams wrote: > > > > > > > > diff --git a/security/keys/key.c b/security/keys/key.c > > > > > index 696f1c092c50..9045b62afb04 100644 > > > > > --- a/security/keys/key.c > > > > > +++ b/security/keys/key.c > > > > > @@ -706,6 +706,7 @@ struct key_type *key_type_lookup(const char *type) > > > > > found_kernel_type: > > > > > return ktype; > > > > > } > > > > > +EXPORT_SYMBOL_GPL(key_type_lookup); > > > > > > This needs to be moved to patch1. > > > > > > > Only the kernel is calling key_type_lookup(). Why does > > > > key_type_lookup() need to be exported? > > > > > > This patch series adds several new callers outside of keys-subsystem > > > core that need this export, the first one being encrypted-keys itself > > > in patch1. > > > > It's needed, because they could be compiled as kernel modules, not > > builtin (eg. EVM). > > > > Right, but now I realize a problem. The side effect of having direct > module dependencies to the key_type_{encrypted,trusted} symbols is > that module reference counting is handled automatically. > > So, I need to respin this with some explicit try_module_get() and > module_put() added otherwise the encrypted_keys facility can be > removed while active keys are instantiated. ...and now I'm wondering if this refactoring is getting too big and should wait for v5.2. In the meantime apply my small fix for v5.1 https://patchwork.kernel.org/patch/10858649/