Find the mkdir system call code

In the first year of my acquaintance with Ubuntu, I became interested in how the kernel of this OS works. I decided with all seriousness to figure it out, downloaded the 80-megabyte source archive, and ... that's it! I did not know where to start, nor how to end. I opened random files in turn and got lost right there. I think this happened with every experienced Linuxoid. Now I have gained experience and would like to share it.

In this article I will explain how I searched for the mkdir system call code.

To begin with, the mkdir function is defined in sys/stat.h. The prototype is as follows:

/* Create a new directory named PATH, with permission bits MODE.  */
extern int mkdir (__const char *__path, __mode_t __mode)
     __THROW __nonnull ((1));

This header file is part of the POSIX standard. Linux is almost completely POSIX-compatible, which means it must implement mkdir with just such a signature.

But even knowing the signature, to find the actual system call code is not at all easy ...

And in truth it ack "int mkdir"will return:

security / inode.c
103: static int mkdir (struct inode * dir, struct dentry * dentry, int mode)

tools / perf / util / util.c
4: int mkdir_p (char * path, mode_t mode)

tools / perf / util /util.h
259: int mkdir_p (char * path, mode_t mode);

It is clear that not a single signature completely matches. Where is the mkdir function implementation located? What is the algorithm for finding implementations of system calls in the Linux kernel?

System calls do not work like regular functions. More precisely, they are not functions at all. To execute a system call, you need some assembler code. By and large, the system call number is placed in the EAX register (by the way, system calls are accessed by the number, not the address), the remaining registers put the arguments: the first in EBX, the second in ECX, the third in EDX, the fourth in ESX, fifth in EDI. By the way, this is why a system call cannot have more than 5 arguments. After all the necessary values ​​are located, the program that wants to make a system call executes the 128th interrupt (on assembler: int 0x80). Interruption puts the processor in kernel mode and transfers control to an address previously agreed with the kernel. As you can see, system calls operate at a lower level than C-functions.

The number of any system call can be found in usr/include/asm*/unistd.h:

#define __NR_mkdir                              83
__SYSCALL(__NR_mkdir, sys_mkdir)

That is, the mkdir system call is number 83.

If you programmed into user space under Linux, you most likely know that, as a rule, C functions are used to make system calls. Where do they come from? Those functions are just wrappers from the GNU libc library. Each system call has a wrapper function. The functions themselves do all the same interrupts.

So where to look for mkdir now? In theory, a system call could be implemented simply in assembler, then the corresponding C-function would simply not exist, but this is not so. On Linux, every system call is defined in include/linux/syscalls.h:

asmlinkage long sys_mkdir(const char __user *pathname, int mode);

The implementation is located in the corresponding part of the kernel. Here you just need to know that mkdir is part of the VFS file subsystem and is defined in fs/namei.c:

SYSCALL_DEFINE2(mkdir, const char __user *, pathname, umode_t, mode)
{
	return sys_mkdirat(AT_FDCWD, pathname, mode);
}

SYSCALL_DEFINE2 is one of the macros in the SYSCALL_DEFINEx series, where x is the number of arguments to the system call. In the code above, another system call is called - sys_mkdirat, which is also located in fs/namei.c. Please note that here the system call is made by calling the function, because the calling code is already executing in kernel mode.

SYSCALL_DEFINE3(mkdirat, int, dfd, const char __user *, pathname, umode_t, mode)
{
	struct dentry *dentry;
	struct path path;
	int error;
	dentry = user_path_create(dfd, pathname, &path, 1);
	if (IS_ERR(dentry))
		return PTR_ERR(dentry);
	if (!IS_POSIXACL(path.dentry->d_inode))
		mode &= ~current_umask();
	error = security_path_mkdir(&path, dentry, mode);
	if (!error)
		error = vfs_mkdir(path.dentry->d_inode, dentry, mode);
	done_path_create(&path, dentry);
	return error;
}

And here is already interesting! We meet the first checks and again the transfer of control to another function - vfs_mkdir, which is defined all in the same fs/namei.h:

int vfs_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode)
{
	int error = may_create(dir, dentry);
	unsigned max_links = dir->i_sb->s_max_links;
	if (error)
		return error;
	if (!dir->i_op->mkdir)
		return -EPERM;
	mode &= (S_IRWXUGO|S_ISVTX);
	error = security_inode_mkdir(dir, dentry, mode);
	if (error)
		return error;
	if (max_links && dir->i_nlink >= max_links)
		return -EMLINK;
	error = dir->i_op->mkdir(dir, dentry, mode);
	if (!error)
		fsnotify_mkdir(dir, dentry);
	return error;
}

Another check, another transfer of control. It is worth saying that Linux is a very multi-level system, where responsibilities are distributed across different parts of the system. Therefore, it is not strange that in the code above, logic is constantly delegated. In the last piece of code, dir-> i_op-> mkdir (dir, dentry, mode) is called. Follow the trail! dir is of type inode *. From the definition of the inode structure, we learn that the i_op pointer is of type inode_operations *. The last structure contains pointers to the functions of operations that can be done on this node, and the implementations are different for different file systems. That is, depending on which file system our dir belongs to, the inode_operations structure will contain pointers to certain implementations.

For example, for ext4, we find the implementation of mkdir in fs / ext4 / namei.c



Understanding the operation of the kernel is a useful skill in the arsenal of any Linuxoid. Hope this article has been helpful too!

Resources:
Linux system call table Linux
sources 3.6
Discussion on unix.stackexchange.com