All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fuchs <fuchsfl@gmail.com>
To: Adrian McMenamin <adrianmcmenamin@gmail.com>
Cc: linux-sh@vger.kernel.org,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Artur Rojek <contact@artur-rojek.eu>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] cdrom: gdrom: update gendisk capacity on open
Date: Mon, 6 Apr 2026 17:12:18 +0200	[thread overview]
Message-ID: <adPNUiKm-PmM2xn5@lithos> (raw)
In-Reply-To: <CACwZE5TPt2Y2Xn+YSVv+BY=PkGeAVAYgsfeLPtCLYKKqYbrPOA@mail.gmail.com>

On 06 Apr 11:21, Adrian McMenamin wrote:
> On Mon, 6 Apr 2026 at 11:00, Adrian McMenamin <adrianmcmenamin@gmail.com> wrote:
> >
> > Florian,
> >
> > On Mon, 6 Apr 2026 at 10:20, Florian Fuchs <fuchsfl@gmail.com> wrote:
> >
> >
> > >
> > > You mean, because one of the functions in the call tree of
> > > gdrom_update_capacity() wants to get the mutex gdrom_mutex or s_umount?
> > > I checked the locally called functions, but don't see that one tries to
> > > aquire a lock.
> > >
> > > I don't understand the exact potential of the race condition, maybe you
> > > can elaborate, where I should look.
> > >
> >
> >
> > Actually, having looked at the code path in detail too I agree that
> > this won't recreate the problem the earlier patch addressed, so this
> > looks good to me.
> 
> 
> Sorry - a further thought. This rechecking for capacity is only truly
> necessary if there has been a change of medium - is that right? So we
> can take the result of the earlier disk_check_media_change and if that
> returns true update the capacity? Is that not correct?

The problem is, that disk_check_media_change(disk) is false on initial
gdrom_bdops_open() when the CD is already in it. It gets true there, if I
swap the disc while running the DC.

So right now, it would check capacity on every gdrom_bdops_open() -
which is mostly on every mount, instead of only if the disk was really
changed in between two mounts.

Regards
Florian

  reply	other threads:[~2026-04-06 15:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-05  8:23 [PATCH 0/2] cdrom: gdrom: fix block I/O and capacity setting Florian Fuchs
2026-04-05  8:23 ` [PATCH 1/2] cdrom: gdrom: replace port I/O with MMIO accessors Florian Fuchs
2026-04-05 13:16   ` Adrian McMenamin
2026-04-06  9:05     ` Florian Fuchs
2026-04-05  8:23 ` [PATCH 2/2] cdrom: gdrom: update gendisk capacity on open Florian Fuchs
2026-04-05 13:24   ` Adrian McMenamin
2026-04-06  9:20     ` Florian Fuchs
2026-04-06 10:00       ` Adrian McMenamin
2026-04-06 10:21         ` Adrian McMenamin
2026-04-06 15:12           ` Florian Fuchs [this message]
2026-04-05 14:09 ` [PATCH 0/2] cdrom: gdrom: fix block I/O and capacity setting John Paul Adrian Glaubitz
2026-04-06  0:58   ` Florian Fuchs

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=adPNUiKm-PmM2xn5@lithos \
    --to=fuchsfl@gmail.com \
    --cc=adrianmcmenamin@gmail.com \
    --cc=contact@artur-rojek.eu \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@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 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.