Re: [question] minix_unlink() is weird or am I stupid?

Andreas Schwab (schwab@issan.cs.uni-dortmund.de)
11 May 1999 11:31:02 +0200


<tigran@aivazian.demon.co.uk> writes:

|> Hi brethren,
|>
|> In fs/minix/namei.c:minix_unlink() there is a section of code that looks
|> like this (with my comments):
|>
|> repeat:
|> retval = -ENOENT;
|> inode = NULL;
|> bh = minix_find_entry(dir, dentry->d_name.name,
|> dentry->d_name.len, &de);
|> if (!bh)
|> goto end_unlink;
|> inode = dentry->d_inode;
|>
|> retval = -EPERM;
|> if (de->inode != inode->i_ino) { /* call this ifA */
|> brelse(bh);
|> current->counter = 0;
|> schedule();
|> goto repeat;
|> }
|> if (de->inode != inode->i_ino) { /* call this ifB */
|> retval = -ENOENT;
|> goto end_unlink;
|> }
|>
|> I don't understand this code. More specifically, how can the code inside
|> ifB ever be executed? If de->inode != inode->i_ino on the first
|> round then when we are scheduled again we would continue on "repeat"
|> label, call minix_find_entry() again (which may cause io so we might fall
|> asleep there too) and so on. To my (unarmed) eyes if de->inode is ever !=
|> inode->i_ino the code inside ifB will never be executed but loop until
|> de->inode == inode->i_ino.

Yes. I'd guess it's just a leftover from the elder days, and the second
condition can be deleted now. There was previously some code between the
statements, which would explain why it was overlooked when ifA was added a
long time ago (assuming that ifB was there before ifA). It also shows
that the minix fs is not really maintained any more.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/