Re: (Lack of) locking, and races in ntfs driver?

[Anonymous]

On Thu, Jun 17, 1999 at 05:00:09PM -0400, Alexander Viro wrote:

> Methink it isn't. Looks like the right thing to do is to keep first 16
> inodes permanently in-core (iget() them upon ->read_super() and keep
> pointers them in ntfs_super_info) and use normal ->i_sem for locking.

What's the difference between inode->i_sem locking and inode->i_state & I_LOCK
locking?

Does one protect the struct inode information whilst the other protects the
"whole inode"?

Apologies if this is a blatantly stupid question.

-- 
20962296