All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Russ Weight <russ.weight@linux.dev>
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>,
	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 13:30:16 -0600	[thread overview]
Message-ID: <6cffe226-928f-360f-20ae-bcf27a8d2c73@amd.com> (raw)
In-Reply-To: <67363ecf8a693_214c294dd@dwillia2-xfh.jf.intel.com.notmuch>

On 11/14/24 12:17, Dan Williams wrote:
> 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.

I believe that is how other similar services, like debugfs, work, the
module is responsible for cleaning up.

Thanks,
Tom

  reply	other threads:[~2024-11-14 19:30 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
2024-11-14 19:30         ` Tom Lendacky [this message]
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=6cffe226-928f-360f-20ae-bcf27a8d2c73@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=aik@amd.com \
    --cc=ashish.kalra@amd.com \
    --cc=bp@alien8.de \
    --cc=dakr@redhat.com \
    --cc=dan.j.williams@intel.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.