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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:26 EST