From: Dan Williams <dan.j.williams@intel.com>
To: Russ Weight <russ.weight@linux.dev>,
Dan Williams <dan.j.williams@intel.com>
Cc: Dionna Glaze <dionnaglaze@google.com>,
<linux-kernel@vger.kernel.org>, <x86@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Danilo Krummrich <dakr@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Tianfei zhang <tianfei.zhang@intel.com>,
<linux-coco@lists.linux.dev>,
Sean Christopherson <seanjc@google.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ashish Kalra <ashish.kalra@amd.com>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
John Allen <john.allen@amd.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Michael Roth <michael.roth@amd.com>,
Alexey Kardashevskiy <aik@amd.com>,
"Russ Weight" <russell.h.weight@intel.com>
Subject: Re: [PATCH v6 3/8] firmware_loader: Move module refcounts to allow unloading
Date: Thu, 14 Nov 2024 10:17:51 -0800 [thread overview]
Message-ID: <67363ecf8a693_214c294dd@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20241114163546.ermxem4bgjzeaxzc@4VRSMR2-DT.corp.robot.car>
Russ Weight wrote:
[..]
> Clearly this would be an unexpected/unusual case. Someone with root
> access would have to remove the device driver. I'm not sure how much
> effort should be expended in preventing it - but this is the reasoning
> behind the incrementing/decrementing of the module reference counts.
The module reference needs to be held only if the producer of those
symbols can be removed without triggering some coordinated removal with
action consumer. A driver that fails to call
firmware_upload_unregister() in its module removal path is simply a driver
with a memory-leak and use-after-free bug, not something the firmware
upload core needs to worry about.
So, the prevention mechanism is "thou shalt use
firmware_upload_unregister() correctly", and when that is in place
explicit module references are not only redundant, but trying to
implement them causes circular dependency loops.
next prev parent reply other threads:[~2024-11-14 18:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 23:22 [PATCH v6 0/8] Add SEV firmware hotloading Dionna Glaze
2024-11-12 23:22 ` [PATCH v6 1/8] KVM: SVM: Fix gctx page leak on invalid inputs Dionna Glaze
2024-11-12 23:22 ` [PATCH v6 2/8] KVM: SVM: Fix snp_context_create error reporting Dionna Glaze
2024-11-13 15:39 ` Tom Lendacky
2024-11-12 23:22 ` [PATCH v6 3/8] firmware_loader: Move module refcounts to allow unloading Dionna Glaze
2024-11-13 2:40 ` Dan Williams
2024-11-13 18:40 ` Dionna Amalie Glaze
2024-11-14 16:35 ` Russ Weight
2024-11-14 18:17 ` Dan Williams [this message]
2024-11-14 19:30 ` Tom Lendacky
2024-11-15 17:28 ` Russ Weight
2024-11-12 23:22 ` [PATCH v6 4/8] crypto: ccp: Fix uapi definitions of PSP errors Dionna Glaze
2024-11-13 16:24 ` Tom Lendacky
2025-02-20 16:34 ` Tom Lendacky
2025-02-20 16:47 ` Borislav Petkov
2025-03-07 20:28 ` Tom Lendacky
2025-03-07 21:21 ` Tom Lendacky
2025-02-21 3:43 ` Herbert Xu
2024-11-12 23:22 ` [PATCH v6 5/8] crypto: ccp: Add GCTX API to track ASID assignment Dionna Glaze
2024-11-13 15:58 ` Sean Christopherson
2024-11-12 23:22 ` [PATCH v6 6/8] crypto: ccp: Add DOWNLOAD_FIRMWARE_EX support Dionna Glaze
2024-11-12 23:22 ` [PATCH v6 7/8] KVM: SVM: Use new ccp GCTX API Dionna Glaze
2024-11-12 23:22 ` [PATCH v6 8/8] KVM: SVM: Delay legacy platform initialization on SNP Dionna Glaze
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67363ecf8a693_214c294dd@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=aik@amd.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=dakr@redhat.com \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dionnaglaze@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=john.allen@amd.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rafael@kernel.org \
--cc=russ.weight@linux.dev \
--cc=russell.h.weight@intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tianfei.zhang@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox