Solaris UFS general rules:

   - If you're holding the inode->i_contents lock
     as RW_WRITER you could update anything in the inode
     and the inode->i_flags without need to hold the
     inode->i_tlock mutex.
      
   - If you're going to update only fields protected by the
     inode->i_tlock you have to hold the inode->i_contents
     lock as RW_READER *before* acquireing the inode->i_tlock mutex.
      
   - If you're not holding the inode->i_contents as RW_READER
     before getting the inode->i_tlock and updating those
     field (as ufs_iput() does) you're busted by several
     other Solaris UFS functions holding the inode->i_contents lock
     as RW_WRITER and do not care about the inode->i_tlock
     while modifiying the inode (Note: this is ok for
     Solaris UFS in general as it follows this protocoll)
      
   - If you're going to aquire the vfs_dqrwlock there are some policies
     with respect to the inode's i_contents lock (and I've seen AFS using
     it...in osi_inode.c) and things will get more complicated with it.
     The main difference in how the i_contents lock is taken should be
     based on whether or not the vfs_dqrwlock is held - if it is,
     then we need a writer lock, otherwise a reader is sufficient.
     that's how it's *supposed* to work.
    
   - At the end, the locking protocoll used by Solaris UFS
     is explained in /usr/include/sys/fs/ufs_inode.h.