Re: [RFC] Change locking in block_dev.c:do_open()

[Richard Gooch <rgooch@ras.ucalgary.ca>]

Alexander Viro writes:
> 
> 
> On Thu, 13 Dec 2001, Richard Gooch wrote:
> 
> > Al, I came up with a proposed solution for this race days ago. After
> > switching to try_inc_mod_count() (based on your first comments), you
> > haven't responded with whether you still see a problem with this
> > approach (your first message implied there were multiple problems).
> 
> Sigh...  Please, take a look at sys_swapon() or get_sb_bdev() or
> devfs_open().  Any version starting with 2.3.46-pre<something> when
> devfs went into the tree.

Wait a minute. Before poking holes at other code paths, can you please
answer the question I'm asking? I repeat: for the devfs revalidate
code, do you see any remaining problems if I increment the module
usage count?

If you want to point out other problem paths, that's fine. But please
answer specific questions so that progress can be made.

> All of them have ->bd_op set from devfs handle and follow that with
> blkdev_get() - directly or indirectly via def_blk_fops.open().  That
> function blocks.  Think what will happen if entry is removed while
> blkdev_get() sleeps on semaphore.

When you say "entry is removed", are you actually referring to a devfs
entry being removed? Or are you talking more generally about the
module being removed?
For the case where devfs_open() is running, the devfs entry remains
valid over the lifetime of the open(). In fact, it remains valid over
the lifetime of the dentry.

> BTW, I'd described that to you several times - last one couple of
> months ago on l-k.

And since then the refcounting code has gone in, and many of your old
concerns have been addressed. I'm trying to engage you in a productive
dialogue to resolve any remaining issues.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca