Re: [BK PATCH] devfs cleanups for 2.5.29

[Richard Gooch]

[Apologies for the late response. I had half a reply composed, then
got distracted by other things]
Roman Zippel writes:
> Hi,
> 
> On Mon, 5 Aug 2002, Richard Gooch wrote:
> 
> > > > Yes. RTFS.
> > >
> > > I'm trying - without getting headache.
> >
> > Take a valium.
> 
> Staying away from devfs sources is cheaper.

Valium might also help you resist taking cheap shots.

> > > In the "devfs=only" case, where is the module count incremented, when a
> > > block device is opened?
> >
> > The module count is incremented when the device is opened,
> > irrespective of whether it's a character or block device, or even a
> > "regular" file.
> 
> Would you please answer my question and tell me where that exactly
> happens in that case?

I've already told you about fops_get(). And for a block device, it's
def_blk_fops.open().

> > > > No. I leverage fops_get(), a common function.
> > >
> > > Which is also insufficiently protected.
> >
> > Incorrect.
> 
> What protects the module from unloading from getting the ops pointer
> until try_inc_mod_count()?

Well, I was going to say that once devfs_unregister() has been called,
you can't get reach devfs_open() for that entry, because the
corresponding dentry is unhashed, and devfs_lookup() won't reach the
entry either.

However, after thinking about it more closely, I note that if you have
already started devfs_open(), and then the module tries to unload,
there is a small window before the call to def_blk_fops.open()/fops_get()
where the ops pointer can become invalid. I've fixed that in my tree,
by using devfs_get_ops(), which safely handles this. I've also added
some comments, to make it clearer.

				Regards,

					Richard....
Permanent: [e-mail]
Current:   [e-mail]