Searched refs:nameidata (Results 1 – 4 of 4) sorted by relevance
563 struct nameidata { struct580 struct nameidata *saved; argument593 struct nameidata *old = current->nameidata; in __set_nameidata()602 current->nameidata = p; in __set_nameidata()618 struct nameidata *now = current->nameidata, *old = now->saved; in restore_nameidata()620 current->nameidata = old; in restore_nameidata()990 struct nameidata *nd = current->nameidata; in nd_jump_link()2474 struct nameidata nd; in filename_lookup()2514 struct nameidata nd; in filename_parentat()3581 struct nameidata nd; in do_filp_open()[all …]
376 Bringing it together with ``struct nameidata``382 in a ``struct nameidata``, "namei" being the traditional name - dating384 converts a "name" to an "inode". ``struct nameidata`` contains (among416 is requested. Keeping a reference in the ``nameidata`` ensures that492 path_lookupat() will unset LOOKUP_JUMPED in nameidata so that in the740 ``struct nameidata`` in the ``m_seq`` field. This one lock and one903 ``seq`` number from the ``nameidata``, so it needs to be extra careful1139 up in the ``nameidata``, and result in pick_link() returning ``NULL``.1142 with "``/``" are detected in pick_link() which resets the ``nameidata``1161 ``nameidata`` in place to point to that target. ``->get_link()`` then[all …]
506 ->lookup() do *not* take struct nameidata anymore; just the flags.512 ->create() doesn't take ``struct nameidata *``; unlike the previous601 nameidata isn't passed at all - nd_jump_link() doesn't need it and609 dentry, it does not get nameidata at all and it gets called only when cookie
53 struct nameidata;1054 struct nameidata *nameidata; member
Completed in 24 milliseconds