Searched refs:nameidata (Results 1 – 4 of 4) sorted by relevance
/Linux-v6.6/fs/ |
D | namei.c | 568 struct nameidata { struct 585 struct nameidata *saved; argument 596 static void __set_nameidata(struct nameidata *p, int dfd, struct filename *name) in __set_nameidata() argument 598 struct nameidata *old = current->nameidata; in __set_nameidata() 607 current->nameidata = p; in __set_nameidata() 610 static inline void set_nameidata(struct nameidata *p, int dfd, struct filename *name, in set_nameidata() 623 struct nameidata *now = current->nameidata, *old = now->saved; in restore_nameidata() 625 current->nameidata = old; in restore_nameidata() 632 static bool nd_alloc_stack(struct nameidata *nd) in nd_alloc_stack() 664 static void drop_links(struct nameidata *nd) in drop_links() [all …]
|
/Linux-v6.6/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-v6.6/include/linux/ |
D | sched.h | 55 struct nameidata; 1080 struct nameidata *nameidata; member
|