On 08/30/2013 04:54 PM, Al Viro wrote:
On Fri, Aug 30, 2013 at 01:43:11PM -0700, Linus Torvalds wrote:
On Fri, Aug 30, 2013 at 1:15 PM, Waiman Long<waiman.long@xxxxxx> wrote:
The prepend_path() isn't all due to getcwd. The correct profile should be
Ugh. I really think that prepend_path() should just be rewritten to
run entirely under RCU.
Then we can remove *all* the stupid locking, and replace it with doing
a read-lock on the rename sequence count, and repeating if requited.
That shouldn't even be hard to do, it just requires mindless massaging
and being careful.
Not really. Sure, you'll retry it if you race with d_move(); that's not
the real problem - access past the end of the object containing ->d_name.name
would screw you and that's what ->d_lock is preventing there. Delayed freeing
of what ->d_name is pointing into is fine, but it's not the only way to get
hurt there...
Actually, prepend_path() was called with rename_lock taken. So d_move()
couldn't be run at the same time. Am I right?
Regards,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
