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