Lines Matching refs:the

1 File management in the Linux kernel
7 Up until 2.6.12, the file descriptor table has been protected
9 ->file_lock protected accesses to all the file related fields
10 of the table. ->count was used for sharing the file descriptor
12 this would be the case for posix threads. As with the common
13 refcounting model in the kernel, the last task doing
14 a put_files_struct() frees the file descriptor (fd) table.
18 In the new lock-free model of file descriptor management,
19 the reference counting is similar, but the locking is
21 elements - the fd sets (open_fds and close_on_exec, the
22 array of file pointers, the sizes of the sets and the array
23 etc.). In order for the updates to appear atomic to
24 a lock-free reader, all the elements of the file descriptor
27 which the actual fd table is accessed. Initially the
30 and files->fdtab points to the new structure. The fdtable
32 see the old fdtable or the new fdtable making the update
33 appear atomic. Here are the locking rules for
34 the fdtable structure -
36 1. All references to the fdtable must be done through
37    the files_fdtable() macro :
51    the memory barrier requirements for lock-free dereference.
52    The fdtable pointer must be read within the read-side
55 2. Reading of the fdtable as described above must be protected
58 3. For any update to the fd table, files->file_lock must
61 4. To look up the file structure given an fd, a reader
76 5. Handling of the file structures is special. Since the look-up
77    of the fd (fget()/fget_light()) are lock-free, it is possible
78    that look-up may race with the last put() operation on the
88 		/* Didn't get the reference, someone's freed */
105 7. While updating, the fdtable pointer must be looked up while
107    another thread expand the files thereby creating a new
108    fdtable and making the earlier fdtable pointer stale.
114 		/* locate_fd() may have expanded fdtable, load the ptr */
122    the fdtable pointer (fdt) must be loaded after locate_fd().