xref: /netbsd-src/share/man/man9/vnode.9 (revision 62a8debe1dc62962e18a1c918def78666141273b)
1.\"     $NetBSD: vnode.9,v 1.47 2010/02/21 13:33:03 wiz Exp $
2.\"
3.\" Copyright (c) 2001, 2005, 2006 The NetBSD Foundation, Inc.
4.\" All rights reserved.
5.\"
6.\" This code is derived from software contributed to The NetBSD Foundation
7.\" by Gregory McGarry.
8.\"
9.\" Redistribution and use in source and binary forms, with or without
10.\" modification, are permitted provided that the following conditions
11.\" are met:
12.\" 1. Redistributions of source code must retain the above copyright
13.\"    notice, this list of conditions and the following disclaimer.
14.\" 2. Redistributions in binary form must reproduce the above copyright
15.\"    notice, this list of conditions and the following disclaimer in the
16.\"    documentation and/or other materials provided with the distribution.
17.\"
18.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
19.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
20.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
21.\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
22.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
23.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
24.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
25.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
26.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
27.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
28.\" POSSIBILITY OF SUCH DAMAGE.
29.\"
30.Dd February 11, 2010
31.Dt VNODE 9
32.Os
33.Sh NAME
34.Nm vnode ,
35.Nm vref ,
36.Nm vrele ,
37.Nm vrele_async ,
38.Nm vget ,
39.Nm vput ,
40.Nm vhold ,
41.Nm holdrele ,
42.Nm getnewvnode ,
43.Nm ungetnewvnode ,
44.Nm vrecycle ,
45.Nm vgone ,
46.Nm vgonel ,
47.Nm vflush ,
48.Nm vaccess ,
49.Nm bdevvp ,
50.Nm cdevvp ,
51.Nm vfinddev ,
52.Nm vdevgone ,
53.Nm vwakeup ,
54.Nm vflushbuf ,
55.Nm vinvalbuf ,
56.Nm vtruncbuf ,
57.Nm vprint
58.Nd kernel representation of a file or directory
59.Sh SYNOPSIS
60.In sys/param.h
61.In sys/vnode.h
62.Ft void
63.Fn vref "struct vnode *vp"
64.Ft void
65.Fn vrele "struct vnode *vp"
66.Ft void
67.Fn vrele_async "struct vnode *vp"
68.Ft int
69.Fn vget "struct vnode *vp" "int lockflag"
70.Ft void
71.Fn vput "struct vnode *vp"
72.Ft void
73.Fn vhold "struct vnode *vp"
74.Ft void
75.Fn holdrele "struct vnode *vp"
76.Ft int
77.Fn getnewvnode "enum vtagtype tag" "struct mount *mp" "int (**vops)(void *)" "struct vnode **vpp"
78.Ft void
79.Fn ungetnewvnode "struct vnode *vp"
80.Ft int
81.Fn vrecycle "struct vnode *vp" "struct simplelock *inter_lkp" "struct lwp *l"
82.Ft void
83.Fn vgone "struct vnode *vp"
84.Ft void
85.Fn vgonel "struct vnode *vp" "struct lwp *l"
86.Ft int
87.Fn vflush "struct mount *mp" "struct vnode *skipvp" "int flags"
88.Ft int
89.Fn vaccess "enum vtype type" "mode_t file_mode" "uid_t uid" "gid_t gid" "mode_t acc_mode" "kauth_cred_t cred"
90.Ft int
91.Fn bdevvp "dev_t dev" "struct vnode **vpp"
92.Ft int
93.Fn cdevvp "dev_t dev" "struct vnode **vpp"
94.Ft int
95.Fn vfinddev "dev_t dev" "enum vtype" "struct vnode **vpp"
96.Ft void
97.Fn vdevgone "int maj" "int minl" "int minh" "enum vtype type"
98.Ft void
99.Fn vwakeup "struct buf *bp"
100.Ft void
101.Fn vflushbuf "struct vnode *vp" "int sync"
102.Ft int
103.Fn vinvalbuf "struct vnode *vp" "int flags" "kauth_cred_t cred" "struct lwp *l" "int slpflag" "int slptimeo"
104.Ft int
105.Fn vtruncbuf "struct vnode *vp" "daddr_t lbn" "int slpflag" "int slptimeo"
106.Ft void
107.Fn vprint "const char *label" "struct vnode *vp"
108.Sh DESCRIPTION
109The vnode is the focus of all file activity in
110.Nx .
111There is a unique vnode allocated for each active file, directory,
112mounted-on file, fifo, domain socket, symbolic link and device.
113The kernel has no concept of a file's underlying structure and so it
114relies on the information stored in the vnode to describe the file.
115Thus, the vnode associated with a file holds all the administration
116information pertaining to it.
117.Pp
118When a process requests an operation on a file, the
119.Xr vfs 9
120interface passes control to a file system type dependent function to carry
121out the operation.
122If the file system type dependent function finds that a vnode
123representing the file is not in main memory, it dynamically allocates
124a new vnode from the system main memory pool.
125Once allocated, the vnode is attached to the data structure pointer
126associated with the cause of the vnode allocation and it remains
127resident in the main memory until the system decides that it is no
128longer needed and can be recycled.
129.Pp
130The vnode has the following structure:
131.Bd -literal
132struct vnode {
133        struct uvm_object v_uobj;               /* uvm object */
134#define v_usecount      v_uobj.uo_refs
135#define v_interlock     v_uobj.vmobjlock
136        voff_t          v_size;                 /* size of file */
137        int             v_flag;                 /* flags */
138        int             v_numoutput;            /* num pending writes */
139        long            v_writecount;           /* ref count of writers */
140        long            v_holdcnt;              /* page \*[Am] buffer refs */
141        struct mount    *v_mount;               /* ptr to vfs we are in */
142        int             (**v_op)(void *);       /* vnode ops vector */
143        TAILQ_ENTRY(vnode) v_freelist;          /* vnode freelist */
144        LIST_ENTRY(vnode) v_mntvnodes;          /* vnodes for mount pt */
145        struct buflists v_cleanblkhd;           /* clean blocklist head */
146        struct buflists v_dirtyblkhd;           /* dirty blocklist head */
147        LIST_ENTRY(vnode) v_synclist;           /* dirty vnodes */
148        LIST_HEAD(, namecache) v_dnclist;       /* namecaches for children */
149        LIST_HEAD(, namecache) v_nclist;        /* namecaches for our parent */
150        union {
151                struct mount    *vu_mountedhere;/* ptr to mounted vfs */
152                struct socket   *vu_socket;     /* unix ipc (VSOCK) */
153                struct specinfo *vu_specinfo;   /* device (VCHR, VBLK) */
154                struct fifoinfo *vu_fifoinfo;   /* fifo (VFIFO) */
155        } v_un;
156#define v_mountedhere   v_un.vu_mountedhere
157#define v_socket        v_un.vu_socket
158#define v_specinfo      v_un.vu_specinfo
159#define v_fifoinfo      v_un.vu_fifoinfo
160        struct nqlease  *v_lease;               /* Soft ref to lease */
161        enum vtype      v_type;                 /* vnode type */
162        enum vtagtype   v_tag;                  /* underlying data type */
163        struct lock     v_lock;                 /* lock for this vnode */
164        struct lock     *v_vnlock;              /* ptr to vnode lock */
165        void            *v_data;                /* private data for fs */
166        struct klist    v_klist;                /* knotes attached to vnode */
167};
168.Ed
169.Pp
170Most members of the vnode structure should be treated as opaque and
171only manipulated using the proper functions.
172There are some rather common exceptions detailed throughout this page.
173.Pp
174Files and file systems are inextricably linked with the virtual memory
175system and
176.Em v_uobj
177contains the data maintained by the virtual memory system.
178For compatibility with code written before the integration of
179.Xr uvm 9
180into
181.Nx ,
182C-preprocessor directives are used to alias the members of
183.Em v_uobj .
184.Pp
185Vnode flags are recorded by
186.Em v_flag .
187Valid flags are:
188.Pp
189.Bl -tag -offset indent -width VONWORKLST -compact
190.It VROOT
191This vnode is the root of its file system.
192.It VTEXT
193This vnode is a pure text prototype.
194.It VSYSTEM
195This vnode is being used by the kernel; only used to skip quota files in
196.Fn vflush .
197.It VISTTY
198This vnode represents a tty; used when reading dead vnodes.
199.It VEXECMAP
200This vnode has executable mappings.
201.It VWRITEMAP
202This vnode might have PROT_WRITE user mappings.
203.It VWRITEMAPDIRTY
204This vnode might have dirty pages due to VWRITEMAP
205.It VLOCKSWORK
206This vnode's file system supports locking.
207.It VXLOCK
208This vnode is currently locked to change underlying type.
209.It VXWANT
210A process is waiting for this vnode.
211.It VBWAIT
212Waiting for output associated with this vnode to complete.
213.It VALIASED
214This vnode has an alias.
215.It VDIROP
216This vnode is involved in a directory operation.
217This flag is used exclusively by LFS.
218.It VLAYER
219This vnode is on a layered file system.
220.It VONWORKLST
221This vnode is on syncer work-list.
222.It VFREEING
223This vnode is being freed.
224.It VMAPPED
225This vnode might have user mappings.
226.El
227.Pp
228The VXLOCK flag is used to prevent multiple processes from entering
229the vnode reclamation code.
230It is also used as a flag to indicate that reclamation is in progress.
231The VXWANT flag is set by threads that wish to be awakened when
232reclamation is finished.
233Before
234.Em v_flag
235can be modified, the
236.Em v_interlock
237simplelock must be acquired.
238See
239.Xr lock 9
240for details on the kernel locking API.
241.Pp
242Each vnode has three reference counts:
243.Em v_usecount ,
244.Em v_writecount
245and
246.Em v_holdcnt .
247The first is the number of active references within the
248kernel to the vnode.
249This count is maintained by
250.Fn vref ,
251.Fn vrele ,
252.Fn vrele_async ,
253and
254.Fn vput .
255The second is the number of active references within the kernel to the
256vnode performing write access to the file.
257It is maintained by the
258.Xr open 2
259and
260.Xr close 2
261system calls.
262The third is the number of references within the kernel
263requiring the vnode to remain active and not be recycled.
264This count is maintained by
265.Fn vhold
266and
267.Fn holdrele .
268When both the
269.Em v_usecount
270and
271.Em v_holdcnt
272reach zero, the vnode is recycled to the freelist and may be reused
273for another file.
274The transition to and from the freelist is handled by
275.Fn getnewvnode ,
276.Fn ungetnewvnode
277and
278.Fn vrecycle .
279Access to
280.Em v_usecount ,
281.Em v_writecount
282and
283.Em v_holdcnt
284is also protected by the
285.Em v_interlock
286simplelock.
287.Pp
288The number of pending synchronous and asynchronous writes on the
289vnode are recorded in
290.Em v_numoutput .
291It is used by
292.Xr fsync 2
293to wait for all writes to complete before returning to the user.
294Its value must only be modified at splbio (see
295.Xr spl 9 ) .
296It does not track the number of dirty buffers attached to the
297vnode.
298.Pp
299.Em v_dnclist
300and
301.Em v_nclist
302are used by
303.Xr namecache 9
304to maintain the list of associated entries so that
305.Xr cache_purge 9
306can purge them.
307.Pp
308The link to the file system which owns the vnode is recorded by
309.Em v_mount .
310See
311.Xr vfsops 9
312for further information of file system mount status.
313.Pp
314The
315.Em v_op
316pointer points to its vnode operations vector.
317This vector describes what operations can be done to the file associated
318with the vnode.
319The system maintains one vnode operations vector for each file system
320type configured into the kernel.
321The vnode operations vector contains a pointer to a function for
322each operation supported by the file system.
323See
324.Xr vnodeops 9
325for a description of vnode operations.
326.Pp
327When not in use, vnodes are kept on the freelist through
328.Em v_freelist .
329The vnodes still reference valid files but may be reused to refer to a
330new file at any time.
331When a valid vnode which is on the freelist is used again, the user
332must call
333.Fn vget
334to increment the reference count and retrieve it from the freelist.
335When a user wants a new vnode for another file,
336.Fn getnewvnode
337is invoked to remove a vnode from the freelist and initialize it for
338the new file.
339.Pp
340The type of object the vnode represents is recorded by
341.Em v_type .
342It is used by generic code to perform checks to ensure operations are
343performed on valid file system objects.
344Valid types are:
345.Pp
346.Bl -tag -offset indent -width VFIFO -compact
347.It VNON
348The vnode has no type.
349.It VREG
350The vnode represents a regular file.
351.It VDIR
352The vnode represents a directory.
353.It VBLK
354The vnode represents a block special device.
355.It VCHR
356The vnode represents a character special device.
357.It VLNK
358The vnode represents a symbolic link.
359.It VSOCK
360The vnode represents a socket.
361.It VFIFO
362The vnode represents a pipe.
363.It VBAD
364The vnode represents a bad file (not currently used).
365.El
366.Pp
367Vnode tag types are used by external programs only (e.g.,
368.Xr pstat 8 ) ,
369and should never be inspected by the kernel.
370Its use is deprecated
371since new
372.Em v_tag
373values cannot be defined for loadable file systems.
374The
375.Em v_tag
376member is read-only.
377Valid tag types are:
378.Pp
379.Bl -tag -offset indent -width "VT_FILECORE " -compact
380.It VT_NON
381non file system
382.It VT_UFS
383universal file system
384.It VT_NFS
385network file system
386.It VT_MFS
387memory file system
388.It VT_MSDOSFS
389FAT file system
390.It VT_LFS
391log-structured file system
392.It VT_LOFS
393loopback file system
394.It VT_FDESC
395file descriptor file system
396.It VT_NULL
397null file system layer
398.It VT_UMAP
399uid/gid remapping file system layer
400.It VT_KERNFS
401kernel interface file system
402.It VT_PROCFS
403process interface file system
404.It VT_AFS
405AFS file system
406.It VT_ISOFS
407ISO 9660 file system(s)
408.It VT_UNION
409union file system
410.It VT_ADOSFS
411Amiga file system
412.It VT_EXT2FS
413Linux's ext2 file system
414.It VT_CODA
415Coda file system
416.It VT_FILECORE
417filecore file system
418.It VT_NTFS
419Microsoft NT's file system
420.It VT_VFS
421virtual file system
422.It VT_OVERLAY
423overlay file system
424.It VT_SMBFS
425SMB file system
426.It VT_PTYFS
427pseudo-terminal device file system
428.It VT_TMPFS
429efficient memory file system
430.It VT_UDF
431universal disk format file system
432.It VT_SYSVBFS
433systemV boot file system
434.El
435.Pp
436All vnode locking operations use
437.Em v_vnlock .
438This lock is acquired by calling
439.Xr vn_lock 9
440and released by calling
441.Xr VOP_UNLOCK 9 .
442The reason for this asymmetry is that
443.Xr vn_lock 9
444is a wrapper for
445.Xr VOP_LOCK 9
446with extra checks, while the unlocking step usually does not need
447additional checks and thus has no wrapper.
448.Pp
449The vnode locking operation is complicated because it is used for many
450purposes.
451Sometimes it is used to bundle a series of vnode operations (see
452.Xr vnodeops 9 )
453into an atomic group.
454Many file systems rely on it to prevent race conditions in updating
455file system type specific data structures rather than using their
456own private locks.
457The vnode lock can operate as a multiple-reader (shared-access lock)
458or single-writer lock (exclusive access lock), however many current file
459system implementations were written assuming only single-writer
460locking.
461Multiple-reader locking functions equivalently only in the presence
462of big-lock SMP locking or a uni-processor machine.
463The lock may be held while sleeping.
464While the
465.Em v_vnlock
466is acquired, the holder is guaranteed that the vnode will not be
467reclaimed or invalidated.
468Most file system functions require that you hold the vnode lock on entry.
469See
470.Xr lock 9
471for details on the kernel locking API.
472.Pp
473For leaf file systems (such as ffs, lfs, msdosfs, etc),
474.Em v_vnlock
475will point to
476.Em v_lock .
477For stacked file systems,
478.Em v_vnlock
479will generally point to
480.Em v_vlock
481of the lowest file system.
482Additionally, the implementation of the vnode lock is the
483responsibility of the individual file systems and
484.Em v_vnlock
485may also be NULL indicating that a leaf node does not export a lock
486for vnode locking.
487In this case, stacked file systems (such as nullfs) must call the
488underlying file system directly for locking.
489.Pp
490Each file system underlying a vnode allocates its own private area and
491hangs it from
492.Em v_data .
493.Pp
494Most functions discussed in this page that operate on vnodes cannot be
495called from interrupt context.
496The members
497.Em v_numoutput ,
498.Em v_holdcnt ,
499.Em v_dirtyblkhd ,
500.Em v_cleanblkhd ,
501.Em v_freelist ,
502and
503.Em v_synclist
504are modified in interrupt context and must be protected by
505.Xr splbio 9
506unless it is certain that there is no chance an interrupt handler will
507modify them.
508The vnode lock must not be acquired within interrupt context.
509.Sh FUNCTIONS
510.Bl -tag -width compact
511.It Fn vref "vp"
512Increment
513.Em v_usecount
514of the vnode
515.Em vp .
516Any kernel thread system which uses a vnode (e.g., during the operation
517of some algorithm or to store in a data structure) should call
518.Fn vref .
519.It Fn vrele "vp"
520Decrement
521.Em v_usecount
522of unlocked vnode
523.Em vp .
524Any code in the system which is using a vnode should call
525.Fn vrele
526when it is finished with the vnode.
527If
528.Em v_usecount
529of the vnode reaches zero and
530.Em v_holdcnt
531is greater than zero, the vnode is placed on the holdlist.
532If both
533.Em v_usecount
534and
535.Em v_holdcnt
536are zero, the vnode is placed on the freelist.
537.It Fn vrele_async "vp"
538Will asychronously release the vnode in different context than the caller,
539sometime after the call.
540.It Fn vget "vp" "lockflags"
541Reclaim vnode
542.Fa vp
543from the freelist, increment its reference count and lock it.
544The argument
545.Fa lockflags
546specifies the
547.Xr lockmgr 9
548flags used to lock the vnode.
549If the VXLOCK is set in
550.Fa vp Ns 's
551.Em v_flag ,
552vnode
553.Fa vp
554is being recycled in
555.Fn vgone
556and the calling thread sleeps until the transition is complete.
557When it is awakened, an error is returned to indicate that the vnode is
558no longer usable (possibly having been recycled to a new file system type).
559.It Fn vput "vp"
560Unlock vnode
561.Fa vp
562and decrement its
563.Em v_usecount .
564Depending on the reference counts, move the vnode to the holdlist or
565the freelist.
566This operation is functionally equivalent to calling
567.Xr VOP_UNLOCK 9
568followed by
569.Fn vrele .
570.It Fn vhold "vp"
571Mark the vnode
572.Fa vp
573as active by incrementing
574.Em vp-\*[Gt]v_holdcnt
575and moving the vnode from the freelist to the holdlist.
576Once on the holdlist, the vnode will not be recycled until it is
577released with
578.Fn holdrele .
579.It Fn holdrele "vp"
580Mark the vnode
581.Fa vp
582as inactive by decrementing
583.Em vp-\*[Gt]v_holdcnt
584and moving the vnode from the holdlist to the freelist.
585.It Fn getnewvnode "tag" "mp" "vops" "vpp"
586Retrieve the next vnode from the freelist.
587.Fn getnewvnode
588must choose whether to allocate a new vnode or recycle an existing
589one.
590The criterion for allocating a new one is that the total number of
591vnodes is less than the number desired or there are no vnodes on either
592free list.
593Generally only vnodes that have no buffers associated with them are
594recycled and the next vnode from the freelist is retrieved.
595If the freelist is empty, vnodes on the holdlist are considered.
596The new vnode is returned in the address specified by
597.Fa vpp .
598.Pp
599The argument
600.Fa mp
601is the mount point for the file system requested the new vnode.
602Before retrieving the new vnode, the file system is checked if it is
603busy (such as currently unmounting).
604An error is returned if the file system is unmounted.
605.Pp
606The argument
607.Fa tag
608is the vnode tag assigned to
609.Fa *vpp-\*[Gt]v_tag .
610The argument
611.Fa vops
612is the vnode operations vector of the file system requesting the new
613vnode.
614If a vnode is successfully retrieved zero is returned, otherwise an
615appropriate error code is returned.
616.It Fn ungetnewvnode "vp"
617Undo the operation of
618.Fn getnewvnode .
619The argument
620.Fa vp
621is the vnode to return to the freelist.
622This function is needed for
623.Xr VFS_VGET 9
624which may need to push back a vnode in case of a locking race
625condition.
626.It Fn vrecycle "vp" "inter_lkp" "l"
627Recycle the unused vnode
628.Fa vp
629to the front of the freelist.
630.Fn vrecycle
631is a null operation if the reference count is greater than zero.
632.It Fn vgone "vp"
633Eliminate all activity associated with the unlocked vnode
634.Fa vp
635in preparation for recycling.
636.It Fn vgonel "vp" "p"
637Eliminate all activity associated with the locked vnode
638.Fa vp
639in preparation for recycling.
640.It Fn vflush "mp" "skipvp" "flags"
641Remove any vnodes in the vnode table belonging to mount point
642.Fa mp .
643If
644.Fa skipvp
645is not NULL it is exempt from being flushed.
646The argument
647.Fa flags
648is a set of flags modifying the operation of
649.Fn vflush .
650If FORCECLOSE is not specified, there should not be any active vnodes and
651the error
652.Er EBUSY
653is returned if any are found (this is a user error, not a system error).
654If FORCECLOSE is specified, active vnodes that are found are detached.
655If WRITECLOSE is set, only flush out regular file vnodes open for
656writing.
657SKIPSYSTEM causes any vnodes marked V_SYSTEM to be skipped.
658.It Fn vaccess "type" "file_mode" "uid" "gid" "acc_mode" "cred"
659Do access checking by comparing the file's permissions to the caller's
660desired access type
661.Fa acc_mode
662and credentials
663.Fa cred .
664.It Fn bdevvp "dev" "vpp"
665Create a vnode for a block device.
666.Fn bdevvp
667is used for root file systems, swap areas and for memory file system
668special devices.
669.It Fn cdevvp "dev" "vpp"
670Create a vnode for a character device.
671.Fn cdevvp
672is used for the console and kernfs special devices.
673.It Fn vfinddev "dev" "vtype" "vpp"
674Lookup a vnode by device number.
675The vnode is returned in the address specified by
676.Fa vpp .
677.It Fn vdevgone "int maj" "int min" "int minh" "enum vtype type"
678Reclaim all vnodes that correspond to the specified minor number range
679.Fa minl
680to
681.Fa minh
682(endpoints inclusive) of the specified major
683.Fa maj .
684.It Fn vwakeup "bp"
685Update outstanding I/O count
686.Em vp-\*[Gt]v_numoutput
687for the vnode
688.Em bp-\*[Gt]b_vp
689and do a wakeup if requested and
690.Em vp-\*[Gt]vflag
691has VBWAIT set.
692.It Fn vflushbuf "vp" "sync"
693Flush all dirty buffers to disk for the file with the locked vnode
694.Fa vp .
695The argument
696.Fa sync
697specifies whether the I/O should be synchronous and
698.Fn vflushbuf
699will sleep until
700.Em vp-\*[Gt]v_numoutput
701is zero and
702.Em vp-\*[Gt]v_dirtyblkhd
703is empty.
704.It Fn vinvalbuf "vp" "flags" "cred" "l" "slpflag" "slptimeo"
705Flush out and invalidate all buffers associated with locked vnode
706.Fa vp .
707The argument
708.Fa l
709and
710.Fa cred
711specified the calling process and its credentials.
712The
713.Xr ltsleep 9
714flag and timeout are specified by the arguments
715.Fa slpflag
716and
717.Fa slptimeo
718respectively.
719If the operation is successful zero is returned, otherwise an
720appropriate error code is returned.
721.It Fn vtruncbuf "vp" "lbn" "slpflag" "slptimeo"
722Destroy any in-core buffers past the file truncation length for the
723locked vnode
724.Fa vp .
725The truncation length is specified by
726.Fa lbn .
727.Fn vtruncbuf
728will sleep while the I/O is performed,  The
729.Xr ltsleep 9
730flag and timeout are specified by the arguments
731.Fa slpflag
732and
733.Fa slptimeo
734respectively.
735If the operation is successful zero is returned, otherwise an
736appropriate error code is returned.
737.It Fn vprint "label" "vp"
738This function is used by the kernel to dump vnode information during a
739panic.
740It is only used if the kernel option DIAGNOSTIC is compiled into the kernel.
741The argument
742.Fa label
743is a string to prefix the information dump of vnode
744.Fa vp .
745.El
746.Sh CODE REFERENCES
747This section describes places within the
748.Nx
749source tree where actual code implementing or using the vnode
750framework can be found.
751All pathnames are relative to
752.Pa /usr/src .
753.Pp
754The vnode framework is implemented within the file
755.Pa sys/kern/vfs_subr.c .
756.Sh SEE ALSO
757.Xr intro 9 ,
758.Xr lock 9 ,
759.Xr namecache 9 ,
760.Xr namei 9 ,
761.Xr uvm 9 ,
762.Xr vattr 9 ,
763.Xr vfs 9 ,
764.Xr vfsops 9 ,
765.Xr vnodeops 9 ,
766.Xr vnsubr 9
767.Sh BUGS
768The locking protocol is inconsistent.
769Many vnode operations are passed locked vnodes on entry but release
770the lock before they exit.
771The locking protocol is used in some places to attempt to make a
772series of operations atomic (e.g., access check then operation).
773This does not work for non-local file systems that do not support locking
774(e.g., NFS).
775The
776.Nm
777interface would benefit from a simpler locking protocol.
778