Messages in this thread | | | Date | Wed, 4 Sep 2013 19:48:14 -0700 | Subject | Re: [PATCH] dcache: Translating dentry into pathname without taking rename_lock | From | Linus Torvalds <> |
| |
On Wed, Sep 4, 2013 at 6:49 PM, Waiman Long <waiman.long@hp.com> wrote: > > So what I am going to do is to use memchr() to locate a null > byte within the given length. If one is found, the string must be invalid > and there is no point in doing the copying. Instead, EINVAL will be returned > and the code will check the sequence number then. The memchr() function can > be fast if an architecture-specific version exists.
We don't have an architecture-specific fast version of memchr, because nobody sane has ever cared about that abomination of a function. Also, if rename() overwrites the pathname (switching inline names), I guess a zero could disappear between your memchr and the copy. Although I think we always have an ending NUL byte for the inline case, so that should make sure that memchr would find it *eventually*.
But regardless, that's really not what you want to do.
You should do:
- use the name length as a maximum
- do a byte-at-a-time copy, stopping at a zero (it's going to be faster than memchr anyway)
Then, later on, we can do one that does a word-at-a-time using the CONFIG_DCACHE_WORD_ACCESS magic: we know dentry names are always word-aligned, and we have an efficient "has_zero()" function for finding zero bytes in a word.
Really.
Linus
| |