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 <adPNUiKm-PmM2xn5@lithos>
On 06 Apr 11:21, Adrian McMenamin wrote:
> On Mon, 6 Apr 2026 at 11:00, Adrian McMenamin <[email protected]> wrote:
> >
> > Florian,
> >
> > On Mon, 6 Apr 2026 at 10:20, Florian Fuchs <[email protected]> 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
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.