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

From: Florian Fuchs

Date: Mon Apr 06 2026 - 05:22:15 EST


On 05 Apr 14:24, Adrian McMenamin wrote:
> On Sun, 5 Apr 2026 at 09:23, Florian Fuchs <fuchsfl@xxxxxxxxx> 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