linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-block@vger.kernel.org
Subject: Re: pktcdvd ->open_mutex lockdep splat
Date: Tue, 26 Mar 2024 11:11:05 -0400	[thread overview]
Message-ID: <ZgLliVcood71SFNE@bfoster> (raw)
In-Reply-To: <ZgC5ydajy7i0f8e8@infradead.org>

On Sun, Mar 24, 2024 at 04:39:53PM -0700, Christoph Hellwig wrote:
> On Fri, Mar 22, 2024 at 01:09:51PM -0400, Brian Foster wrote:
> > Ok, I guess the reason I was only seeing this in one particular VM is
> > that for whatever reason, something happens to invoke pktsetup during
> > boot on that guest. If I boot up a separate VM/distro and run 'pktsetup
> > 0 /dev/sr0,' I see the same splat..
> 
> pktcdvd is completely unmaintained and in horrible shape unfortunately,
> and no one is interested in caring for it.
> 
> I can only recommend to not build it into any kernel you can care about.
> 

Heh, Ok thanks. I was poking around the code a bit just to try and
figure if there was some easy/incremental improvement to be made here,
but if so, I'm not familiar enough with the code to see it. I was
particularly wondering why the multi-open occurs across the setup and
pktcdvd device open and if that can be avoided. It looks like the main
difference is the nonblock flag. From digging down into cdrom_open(),
that is what controls whether or not the drive is opened for data or
control purposes (i.e., so dictates whether media is read or not), and
so that seems to explain why a blocking open would be deferred to
pktcdvd device open.

Anyways, it does seem like the warning itself is benign because the
pktcdvd and backing device will be separate disks.

Brian


      reply	other threads:[~2024-03-26 15:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-22 16:40 pktcdvd ->open_mutex lockdep splat Brian Foster
2024-03-22 17:09 ` Brian Foster
2024-03-24 23:39   ` Christoph Hellwig
2024-03-26 15:11     ` Brian Foster [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=ZgLliVcood71SFNE@bfoster \
    --to=bfoster@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.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;
as well as URLs for NNTP newsgroup(s).