Searched refs:nameidata (Results 1 – 4 of 4) sorted by relevance
| /linux-6.1.9/fs/ |
| D | namei.c | 564 struct nameidata { struct
581 struct nameidata *saved; argument
592 static void __set_nameidata(struct nameidata *p, int dfd, struct filename *name) in __set_nameidata() argument
594 struct nameidata *old = current->nameidata; in __set_nameidata()
603 current->nameidata = p; in __set_nameidata()
606 static inline void set_nameidata(struct nameidata *p, int dfd, struct filename *name, in set_nameidata()
619 struct nameidata *now = current->nameidata, *old = now->saved; in restore_nameidata()
621 current->nameidata = old; in restore_nameidata()
628 static bool nd_alloc_stack(struct nameidata *nd) in nd_alloc_stack()
658 static void drop_links(struct nameidata *nd) in drop_links()
[all …]
|
| /linux-6.1.9/Documentation/filesystems/ |
| D | path-lookup.rst | 376 Bringing it together with ``struct nameidata``
382 in a ``struct nameidata``, "namei" being the traditional name - dating
384 converts a "name" to an "inode". ``struct nameidata`` contains (among
416 is requested. Keeping a reference in the ``nameidata`` ensures that
438 Given a path (``name``) and a nameidata structure (``nd``), check that the
460 otherwise it installs the new ``struct path`` in the ``struct nameidata``, and
492 path_lookupat() will unset LOOKUP_JUMPED in nameidata so that in the
740 ``struct nameidata`` in the ``m_seq`` field. This one lock and one
764 ``seq`` field of the nameidata structure, so ``nd->seq`` should always be
788 access and it is stored in the ``inode`` field of ``nameidata`` from where
[all …]
|
| D | porting.rst | 512 ->lookup() do *not* take struct nameidata anymore; just the flags.
518 ->create() doesn't take ``struct nameidata *``; unlike the previous
607 nameidata isn't passed at all - nd_jump_link() doesn't need it and
615 dentry, it does not get nameidata at all and it gets called only when cookie
|
| /linux-6.1.9/include/linux/ |
| D | sched.h | 55 struct nameidata;
1080 struct nameidata *nameidata; member
|