Re: [BK PATCH] devfs cleanups for 2.5.29

From: Richard Gooch (
Date: Sun Aug 18 2002 - 19:48:16 EST

[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

> > > > 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
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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Fri Aug 23 2002 - 22:00:16 EST