Messages in this thread | | | Date | Thu, 23 Feb 2006 22:00:53 -0800 | From | Andrew Morton <> | Subject | Re: udevd is killing file write performance. |
| |
John McCutchan <john@johnmccutchan.com> wrote: > > > > @@ -538,7 +537,7 @@ > > > struct dentry *parent; > > > struct inode *inode; > > > > > > - if (!atomic_read (&inotify_watches)) > > > + if (!atomic_read (&dentry->d_sb->s_inotify_watches)) > > > return; > > > > > > > What happens here if we're watching a mountpoint - the parent is on a > > different fs? > > There are four cases to consider here. > > Case 1: parent fs watched and child fs watched > correct results > Case 2: parent fs watched and child fs not watched > We may not deliver an event that should be delivered. > Case 3: parent fs not watched and child fs watched > We take d_lock when we don't need to > Case 4: parent fs not watched and child fs not watched > correct results > > Case 2 screws us. We have to take the lock to even look at the parent's > dentry->d_sb->s_inotify_watches. I don't know of a way around this one.
Yeah. There are a lot of "screw"s in this thread.
I wonder if RCU can save us - if we do an rcu_read_lock() we at least know that the dentries won't get deallocated. Then we can take a look at d_parent (which might not be the parent any more). Once in a million years we might send a false event or miss sending an event, depending on where our dentry suddenly got moved to. Not very nice, but at least it won't oops.
(hopefully cc's Dipankar) - 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/
| |