📄 namei.c
字号:
} umsdos_unlockcreate(dir); } } PRINTK (("umsdos_mkdir %d\n",ret)); iput (dir); return ret;}/* Add a new device special file into a directory.*/int UMSDOS_mknod( struct inode * dir, const char * name, int len, int mode, int rdev){ /* #Specification: Special files / strategy Device special file, pipes, etc ... are created like normal file in the msdos file system. Of course they remain empty. One strategy was to create those files only in the EMD file since they were not important for MSDOS. The problem with that, is that there were not getting inode number allocated. The MSDOS filesystems is playing a nice game to fake inode number, so why not use it. The absence of inode number compatible with those allocated for ordinary files was causing major trouble with hard link in particular and other parts of the kernel I guess. */ struct inode *inode; int ret = umsdos_create_any (dir,name,len,mode,rdev,0,&inode); iput (inode); return ret;}/* Remove a sub-directory.*/int UMSDOS_rmdir( struct inode * dir, const char * name, int len){ /* #Specification: style / iput strategy In the UMSDOS project, I am trying to apply a single programming style regarding inode management. Many entry point are receiving an inode to act on, and must do an iput() as soon as they are finished with the inode. For simple case, there is no problem. When you introduce error checking, you end up with many iput placed around the code. The coding style I use all around is one where I am trying to provide independent flow logic (I don't know how to name this). With this style, code is easier to understand but you rapidly get iput() all around. Here is an exemple of what I am trying to avoid. # if (a){ ... if(b){ ... } ... if (c){ // Complex state. Was b true ? ... } ... } // Weird state if (d){ // ... } // Was iput finally done ? return status; # Here is the style I am using. Still sometime I do the first when things are very simple (or very complicated :-( ) # if (a){ if (b){ ... }else if (c){ // A single state gets here } }else if (d){ ... } return status; # Again, while this help clarifying the code, I often get a lot of iput(), unlike the first style, where I can place few "strategic" iput(). "strategic" also mean, more difficult to place. So here is the style I will be using from now on in this project. There is always an iput() at the end of a function (which has to do an iput()). One iput by inode. There is also one iput() at the places where a successful operation is achieved. This iput() is often done by a sub-function (often from the msdos file system). So I get one too many iput() ? At the place where an iput() is done, the inode is simply nulled, disabling the last one. # if (a){ if (b){ ... }else if (c){ msdos_rmdir(dir,...); dir = NULL; } }else if (d){ ... } iput (dir); return status; # Note that the umsdos_lockcreate() and umsdos_unlockcreate() function pair goes against this practice of "forgetting" the inode as soon as possible. */ int ret = umsdos_nevercreat(dir,name,len,-EPERM); if (ret == 0){ struct inode *sdir; dir->i_count++; ret = UMSDOS_lookup (dir,name,len,&sdir); PRINTK (("rmdir lookup %d ",ret)); if (ret == 0){ int empty; umsdos_lockcreate(dir); if (sdir->i_count > 1){ ret = -EBUSY; }else if ((empty = umsdos_isempty (sdir)) != 0){ PRINTK (("isempty %d i_count %d ",empty,sdir->i_count)); /* check sticky bit */ if ( !(dir->i_mode & S_ISVTX) || fsuser() || current->fsuid == sdir->i_uid || current->fsuid == dir->i_uid ) { if (empty == 1){ /* We have to removed the EMD file */ ret = msdos_unlink(sdir,UMSDOS_EMD_FILE ,UMSDOS_EMD_NAMELEN); sdir = NULL; } /* sdir must be free before msdos_rmdir() */ iput (sdir); sdir = NULL; PRINTK (("isempty ret %d nlink %d ",ret,dir->i_nlink)); if (ret == 0){ struct umsdos_info info; dir->i_count++; umsdos_parse (name,len,&info); /* The findentry is there only to complete */ /* the mangling */ umsdos_findentry (dir,&info,2); ret = msdos_rmdir (dir,info.fake.fname ,info.fake.len); if (ret == 0){ ret = umsdos_delentry (dir,&info,1); } } }else{ /* sticky bit set and we don't have permission */ PRINTK(("sticky set ")); ret = -EPERM; } }else{ /* The subdirectory is not empty, so leave it there */ ret = -ENOTEMPTY; } iput(sdir); umsdos_unlockcreate(dir); } } iput (dir); PRINTK (("umsdos_rmdir %d\n",ret)); return ret;}/* Remove a file from the directory.*/int UMSDOS_unlink ( struct inode * dir, const char * name, int len){ int ret = umsdos_nevercreat(dir,name,len,-EPERM); if (ret == 0){ struct umsdos_info info; ret = umsdos_parse (name,len,&info); if (ret == 0){ umsdos_lockcreate(dir); ret = umsdos_findentry(dir,&info,1); if (ret == 0){ PRINTK (("UMSDOS_unlink %s ",info.fake.fname)); /* check sticky bit */ if ( !(dir->i_mode & S_ISVTX) || fsuser() || current->fsuid == info.entry.uid || current->fsuid == dir->i_uid ) { if (info.entry.flags & UMSDOS_HLINK){ /* #Specification: hard link / deleting a link When we deletes a file, and this file is a link we must subtract 1 to the nlink field of the hidden link. If the count goes to 0, we delete this hidden link too. */ /* First, get the inode of the hidden link using the standard lookup function. */ struct inode *inode; dir->i_count++; ret = UMSDOS_lookup (dir,name,len,&inode); if (ret == 0){ PRINTK (("unlink nlink = %d ",inode->i_nlink)); inode->i_nlink--; if (inode->i_nlink == 0){ struct inode *hdir = iget(inode->i_sb ,inode->u.umsdos_i.i_dir_owner); struct umsdos_dirent entry; ret = umsdos_inode2entry (hdir,inode,&entry); if (ret == 0){ ret = UMSDOS_unlink (hdir,entry.name ,entry.name_len); }else{ iput (hdir); } }else{ struct iattr newattrs; newattrs.ia_valid = 0; ret = UMSDOS_notify_change (inode, &newattrs); } iput (inode); } } if (ret == 0){ ret = umsdos_delentry (dir,&info,0); if (ret == 0){ PRINTK (("Avant msdos_unlink %s ",info.fake.fname)); dir->i_count++; ret = msdos_unlink_umsdos (dir,info.fake.fname ,info.fake.len); PRINTK (("msdos_unlink %s %o ret %d ",info.fake.fname ,info.entry.mode,ret)); } } }else{ /* sticky bit set and we've not got permission */ PRINTK(("sticky set ")); ret = -EPERM; } } umsdos_unlockcreate(dir); } } iput (dir); PRINTK (("umsdos_unlink %d\n",ret)); return ret;}/* Rename a file (move) in the file system.*/int UMSDOS_rename( struct inode * old_dir, const char * old_name, int old_len, struct inode * new_dir, const char * new_name, int new_len, int must_be_dir){ /* #Specification: weakness / rename There is a case where UMSDOS rename has a different behavior than normal UNIX file system. Renaming an open file across directory boundary does not work. Renaming an open file within a directory does work however. The problem (not sure) is in the linux VFS msdos driver. I believe this is not a bug but a design feature, because an inode number represent some sort of directory address in the MSDOS directory structure. So moving the file into another directory does not preserve the inode number. */ int ret = umsdos_nevercreat(new_dir,new_name,new_len,-EEXIST); if (ret == 0){ /* umsdos_rename_f eat the inode and we may need those later */ old_dir->i_count++; new_dir->i_count++; ret = umsdos_rename_f (old_dir,old_name,old_len,new_dir,new_name ,new_len,0); if (ret == -EEXIST){ /* #Specification: rename / new name exist If the destination name already exist, it will silently be removed. EXT2 does it this way and this is the spec of SUNOS. So does UMSDOS. If the destination is an empty directory it will also be removed. */ /* #Specification: rename / new name exist / possible flaw The code to handle the deletion of the target (file and directory) use to be in umsdos_rename_f, surrounded by proper directory locking. This was insuring that only one process could achieve a rename (modification) operation in the source and destination directory. This was also insuring the operation was "atomic". This has been changed because this was creating a kernel stack overflow (stack is only 4k in the kernel). To avoid the code doing the deletion of the target (if exist) has been moved to a upper layer. umsdos_rename_f is tried once and if it fails with EEXIST, the target is removed and umsdos_rename_f is done again. This makes the code cleaner and (not sure) solve a deadlock problem one tester was experiencing. The point is to mention that possibly, the semantic of "rename" may be wrong. Anyone dare to check that :-) Be aware that IF it is wrong, to produce the problem you will need two process trying to rename a file to the same target at the same time. Again, I am not sure it is a problem at all. */ /* This is not super efficient but should work */ new_dir->i_count++; ret = UMSDOS_unlink (new_dir,new_name,new_len);chkstk(); PRINTK (("rename unlink ret %d %d -- ",ret,new_len)); if (ret == -EISDIR){ new_dir->i_count++; ret = UMSDOS_rmdir (new_dir,new_name,new_len);chkstk(); PRINTK (("rename rmdir ret %d -- ",ret)); } if (ret == 0){ ret = umsdos_rename_f (old_dir,old_name,old_len ,new_dir,new_name,new_len,0); new_dir = old_dir = NULL; } } } iput (new_dir); iput (old_dir); return ret;}
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -