Messages in this thread | | | Date | Sun, 9 May 2004 02:30:21 +0530 | From | Dipankar Sarma <> | Subject | Re: dentry bloat. |
| |
On Sat, May 08, 2004 at 12:01:48PM -0700, Andrew Morton wrote: > Linus Torvalds <torvalds@osdl.org> wrote: > > Also, in your previous patch (which I'm not as convinced might be wrong), > > the d_qstr pointer removal makes me worry: > > > > - struct qstr * d_qstr; /* quick str ptr used in lockless lookup and concurrent d_move */ > > > > I thought the point of d_qstr was that when we do the lockless lookup, > > we're guaranteed to always see "stable storage" in the sense that when we > > follow the d_qstr, we will always get a "char *" + "len" that match, and > > we could never see a partial update (ie len points to the old one, and > > "char *" points to the new one). > > It looks that way.
Yes, that is exactly why d_qstr was introduced. The "len" and the storage for the name is then a single update through d_qstr.
> > > In particular, think about the "d_compare(parent, qstr, name)" / > > "memcmp(qstr->name, str, len)" part - what if "len" doesn't match str, > > because a concurrent d_move() is updating them, and maybe we will compare > > past the end of kernel mapped memory or something? > > > > (In other words, the "move_count" check should protect us from returning a > > wrong dentry, but I'd worry that we'd do something that could cause > > serious problems before we even get to the "move_count" check). > > > > Hmm?
Yes, that is indeed why we had to have d_qstr.
> I think we can simply take ->d_lock a bit earlier in __d_lookup. That will > serialise against d_move(), fixing the problem which you mention, and also > makes d_movecount go away.
Repeating some of the tests under ->d_lock is worth looking at, but we have to be carefull about performance. ISTR, there was another issue related to calling ->d_compare() under ->d_lock. I will dig a little bit on this, or Maneesh may remember.
Thanks 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/
| |