[1648] in SIPB_Linux_Development
Ted's Linux inode.c patch
daemon@ATHENA.MIT.EDU (Erik Nygren)
Wed Apr 9 20:11:49 1997
To: linux-dev@MIT.EDU, tytso@MIT.EDU
Date: Wed, 09 Apr 1997 20:12:03 EDT
From: Erik Nygren <nygren@MIT.EDU>
I was just looking through inode.c and Ted's patch and I had a
few questions (line numbers relative to 2.0.29).
In iput, i_lock is set (line 460) without any test for
whether it is currently locked. This code was added since
1.2.13 (and as it was the only relavant-looking inode code added since then,
I'm wary of it ;) , but your patch doesn't deal with it at all.
Shouldn't lock_inode be used instead of the explicit set of i_lock ?
There is a wait_on_inode at the top of iput, so using lock_inode
may not be necessary, but it looks like scheduling may happen
after the wait_on_inode where the inode might get locked by
something else.
Some more minor thoughts:
In clear_inode, your patch changes a wait_on_inode to a lock_inode,
but there is no corresponding unlocking of the inode. Where does this
happen? (Does the memset of the inode to 0 handle this? It make
be clearer to use unlock_inode).
write_inode also uses wait_on_inode instead of i_lock instead of
lock_inode, but this is probably safe due to the wait_on_inode
shortly before it.
Also, it looks like __wait_on_inode doesn't return until i_lock is 0,
so the changes to inode_lock shouldn't be necessary....
I'll send out a variant of Ted's patch to try out in a bit...
(Mostly the same thing, but with debugging printk's to log when
a problem would have occurred. I'm also adding a "fix" to iput.
Note that I really don't understand this, so Ted or someone should
sanity check. ;)
Erik
