A brief analysis of the source code of Linux HUGETLBFS kernel-----(ii) HUGETLBFS mount

This article only discusses the execution of the Mount system call (based on Linux-3.4.51) after executing the "Mount none/mnt/huge-t hugetlbfs" command, and does not involve process-related details.

The kernel implementation of the Mount system call:

1Syscall_define5 (Mount,Char__user *, Dev_name,Char__user *, Dir_name,2         Char__user *, type, unsignedLong, Flags,void__user *, data)3 {4     intret;5     Char*Kernel_type;6     Char*Kernel_dir;7     Char*Kernel_dev;8UnsignedLongData_page;9 Ten     /*from the User space copy file system type, the file system type string length cannot be greater than page_size, that is, cannot be large with 4K.  One * Kernel_type = "Hugetlbfs" A      */ -ret = copy_mount_string (type, &kernel_type); -     if(Ret <0) the         GotoOut_type; -  -     /*get mount point from user space, Kerne_dir = "/mnt/huge"*/ -Kernel_dir =getname (dir_name); +     if(Is_err (Kernel_dir)) { -RET =Ptr_err (kernel_dir); +         GotoOut_dir; A     } at      -     /*get mount device from user space, Kernel_dev = "None"*/ -ret = copy_mount_string (Dev_name, &Kernel_dev); -     if(Ret <0) -         GotoOut_dev; -  in     /*get additional parameters for the Mount command*/ -RET = copy_mount_options (data, &data_page); to     if(Ret <0) +         GotoOut_data; -  the     /*Handling specific Mount details*/ *RET =Do_mount (Kernel_dev, Kernel_dir, Kernel_type, Flags, $(void*) data_page);Panax Notoginseng  - free_page (data_page); the Out_data: + Kfree (Kernel_dev); A Out_dev: the Putname (kernel_dir); + Out_dir: - Kfree (kernel_type); $ Out_type: $     returnret; -}

After processing the relevant parameters, the specific mount operation is implemented by the Do_mount () function, Do_mount () is mainly divided into two parts, one is to find the dentry of the loading point, and the other is to create Hugetlbfs Super_block, Vfsmount, An association between a related data structure such as a mount point dentry.

One, Kern_path () Find mount point

path_init (): Find the root directory of the search starting point for the mount point pathname (that is,/mnt/huge), which is stored in the data structure struct nameidata.

Nd->root = current->fs->root;

Nd->path = nd->root;

Nd->inode = nd->path.dentry->d_inode;

Link_path_walk (): The function consists of a cycle that processes the file name or pathname by component. The name is divided into components within the loop (each component is split by one or more "/"). Each component represents a directory name, and the last component is the file name. In each cycle, until the specified file name or directory name is processed and a matching inode is found.

　　

Specific as follows:

1, the character scan path name, slash "/" will be skipped.

2, May_lookup () determine whether the current Inode defines the permission method, to use different methods to determine whether the current process is allowed to enter the directory.

3, judging the current component is "." or ".", If ":", set the flag Last_dotdot, and finally call Walk_component ()--->handle_dots ()--->follow_dotdot () processing. If ".", the flag Last_dot is set.

4, if the normal component, then call Walk_component ()--->do_lookup () processing. Do_lookup () handles the actual lookup work and finds the corresponding dentry of the component. The inode is first looked up from the dentry of the top-level directory, and D_revalidate () is called to check whether the cache entry is valid (that is, if it is consistent with the data in the actual file system), or if it is valid, call __lookup_hash () to continue the lookup, First call Lookup_dcache () to find out if the cache is present, and if it does not, continue calling Lookup_real (), calling the specific file system lookup function.

Do_lookup () also handles the work of tracking mount points, and also needs to determine whether the subordinate directories also mount the file system, __FOLLOW_MOUNT_RCU () is responsible for the specific processing, not discussed here.

5, Nested_symlink () determine whether the component is a symbolic link. Only the inode that represents the symbolic link has a specific value in the LOOKUP function pointer in its inode_operations, otherwise it is null.

Complete_walk (): This function does some checking to see if it is necessary to call D_revalidate () again to determine if the cache entry is valid.

Second, Do_new_mount () Loading file system

Do_new_mount () is divided into two parts: Do_kern_mount () and Do_add_mount ().

Do_kern_mount (): First Call Get_fs_type () to get the corresponding registered file system type. For HUGETLBFS, the corresponding kernel file system type is Hugetlbfs_fs_type. After obtaining the corresponding file system type, first call ALLOC_VFSMNT () to allocate and initialize the Mount data structure, then call MOUNT_FS (), further call Hugetlbfs_mount (), assign the mount point Super_block, Dentry, Inode and establish related mappings. Finally, the mapping between Mount, Super_block and Dentry is established. The specific mapping relationship is shown in the last diagram in the http://www.cnblogs.com/MerlinJ/p/4053689.html article.

Hugetlbfs_mount () did the following work:

1, apply for and initialize a super_block.

2, call Set_anon_super (), get an unused this device number dev, and then set the S_dev field of the new super block with the main device number 0 and the secondary device number dev .

3. Hang the Super_block into the global super_blocks linked list and hang it in the hugetlbfs_fs_type->fs_supers linked list.

4, call Hugetlbfs_fill_super (), create Dentry, inode, and establish the mapping between Dentry, Inode, Super_block.

Do_add_mount (): First determine whether the file system is mounted repeatedly, the same file system cannot be mounted to the same mount point. Call Attach_recursive_mnt () again to add mount points to the global tree, that is, the mount data structure created by Do_kern_mount (), to the global mount_hashtable linked list, to the Mnt_ of the namespace List linked to the mnt_mounts linked list in the parent mount point.

Just a rough walk of the process, a lot of specific details are not involved, there is yet to be added.

Reference:

http://blog.csdn.net/chenjin_zhong/article/details/8448862

http://blog.csdn.net/dndxhej/article/details/7434521

A brief analysis of the source code of Linux HUGETLBFS kernel-----(ii) HUGETLBFS mount