>
> Thank you for taking the time to look over my patch and sending
>your comments. In response, Yes, there is a reason why I can't implement
>path_lookup by calling path_init. path_init calls dget which increments
>the d_count. The function I wrote holds the dcache_lock instead of
>incrementing d_count at that point.
OK, I see what you're doing now.
One obvious problem with it is that __emul_lookup_dentry()[1] calls
path_walk() internally, and the nd passed has uncounted references and
no LOOKUP_LOCKED flag - I suspect that this will cause reference counts
to get mucked up.
Also:
1) you really need to fix the patch whitespace/formatting
2) Please again consider calling it path_lookup() rather than
path_init_walk() - the fact that since 2.3.x programmers have had to be
aware of the separate path_init()/path_walk() stages is an
implementation wrinkle that it would be nice to get rid of.
Paul
[1] Actually, __emul_lookup_dentry() probably ought to be simplified
somewhat - it seems to be duplicating a fair chunk of code from
path_init().
-
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/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:01:09 EST