mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Kyle Zeng <kylebot@openai.com>
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
	Kevin Tian <kevin.tian@intel.com>,
	outbounddisclosures@openai.com
Subject: Re: [PATCH 1/2] vfio: Publish the container after all fallible initialization
Date: Mon, 2 Nov 2026 21:12:41 -0400	[thread overview]
Message-ID: <20261103011241.GA2696898@ziepe.ca> (raw)
In-Reply-To: <20261031042527.6418-1-kylebot@openai.com>

On Fri, Oct 30, 2026 at 09:25:26PM -0700, Kyle Zeng wrote:
> vfio_group_init() publishes /dev/vfio/vfio before vfio_init() has
> finished. The optional no-IOMMU backend is also registered after the
> misc device. A concurrent open can therefore obtain a container while
> the module is still COMING, even if a later initialization step fails.

You didn't cc the vfio maintainers or the its list.

Nor did you refer to my prior remarks here:

https://lore.kernel.org/all/20261030120845.GA3889730@ziepe.ca/

> The failed-module-init path frees the module without waiting for these
> open files.

This is a cdev core bug. It should not allow the file to be opened
until it has secured a module refcount. I don't know much about how
the module refcounting mechanisms work, but it is unreasonable to fix
it like you are doing here by hacking every misc user in the kernel.

Jason

      parent reply	other threads:[~2026-11-03  1:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-31  4:25 Kyle Zeng
2026-10-31  4:25 ` [PATCH 2/2] iommufd: Reject opens until module initialization succeeds Kyle Zeng
2026-11-02 21:28 ` [PATCH 1/2] vfio: Publish the container after all fallible initialization Alex Williamson
2026-11-03  1:12 ` Jason Gunthorpe [this message]

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=20261103011241.GA2696898@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=iommu@lists.linux.dev \
    --cc=kevin.tian@intel.com \
    --cc=kylebot@openai.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=outbounddisclosures@openai.com \
    /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

all inboxes | Powered by JetHome®