[RFC] lustre treatment of dentry->d_name
Al Viro <viro <at> ZenIV.linux.org.uk>
2014-10-21 01:13:46 GMT
a) what protects ->d_name in ll_intent_file_open()? It copies
->d_name.name and ->d_name.len into local variables and proceeds to
use those; what's to guarantee that dentry won't get hit with d_move()
halfway through that? None of the locks that would give an exclusion
against d_move() appear to be held...
b) what stabilizes *dentryp->d_name in do_statahead_enter()?
c) what stabilizes fdentry->d_parent->d_name in llog_lvfs_destroy()?
Unless I'm missing something subtle, all three can race with d_move(),
with obvious unpleasant results. The next bunch doesn't (the callers
are holding ->i_mutex on parents), but it's also bloody odd - why are we
playing these games in llite/namei.c?
static int ll_mkdir(struct inode *dir, struct dentry *dentry, ll_umode_t mode)
return ll_mkdir_generic(dir, &dentry->d_name, mode, dentry);
static int ll_mkdir_generic(struct inode *dir, struct qstr *name,
int mode, struct dentry *dchild)
CDEBUG(D_VFSTRACE, "VFS Op:name=%.*s,dir=%lu/%u(%p)\n",
name->len, name->name, dir->i_ino, dir->i_generation, dir);
if (!IS_POSIXACL(dir) || !exp_connect_umask(ll_i2mdexp(dir)))
mode &= ~current_umask();