Re: [PATCH 2/2] cdrom: gdrom: update gendisk capacity on open

[Florian Fuchs <fuchsfl@gmail.com>]

On 05 Apr 14:24, Adrian McMenamin wrote:
> On Sun, 5 Apr 2026 at 09:23, Florian Fuchs <fuchsfl@gmail.com> wrote:
> >
> > Update the gendisk capacity of the media. Without the capacity, the block
> > reads fail before reaching the request queue, which prevented ISO9660
> > mounts. Refresh the capacity from the TOC leadout in gdrom_bdops_open()
> > so it checks the inserted media.
> >
> ...
> > +
> >  static int gdrom_bdops_open(struct gendisk *disk, blk_mode_t mode)
> >  {
> >         int ret;
> > @@ -492,6 +511,8 @@ static int gdrom_bdops_open(struct gendisk *disk, blk_mode_t mode)
> >
> >         mutex_lock(&gdrom_mutex);
> >         ret = cdrom_open(gd.cd_info, mode);
> > +       if (!ret)
> > +               ret = gdrom_update_capacity();
> >         mutex_unlock(&gdrom_mutex);
> >         return ret;
> >  }
> 
> 
> Will this not reintrocue the potential race condition bug that was
> eliminated here -
> https://github.com/mcmenaminadrian/linux/commit/2bbea6e117357d17842114c65e9a9cf2d13ae8a3
> (not by me, I add)?

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.

Thank You!
Regards
Florian