Messages in this thread |  | | Date | Sun, 18 Aug 2002 18:48:16 -0600 | From | Richard Gooch <> | Subject | Re: [BK PATCH] devfs cleanups for 2.5.29 |
| |
[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: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |