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

Florian Fuchs <[email protected]>
Newsgroups gmane.linux.ports.sh.devel,gmane.linux.kernel
Message-ID <adN68wCJd6QEZyNW@lithos>
On 05 Apr 14:24, Adrian McMenamin wrote:
> On Sun, 5 Apr 2026 at 09:23, Florian Fuchs <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.