On Thu, 12 Apr 2001, Linus Torvalds wrote:
>
>
> On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
> >
> > Comments?
> >
> > --- fs/inode.c~ Thu Mar 22 16:04:13 2001
> > +++ fs/inode.c Thu Apr 12 15:18:22 2001
> > @@ -347,6 +347,11 @@
> > #endif
> >
> > spin_lock(&inode_lock);
> > + while (inode->i_state & I_LOCK) {
> > + spin_unlock(&inode_lock);
> > + __wait_on_inode(inode);
> > + spin_lock(&inode_lock);
> > + }
> > if (!(inode->i_state & I_DIRTY))
> > goto out;
> > if (datasync && !(inode->i_state & I_DIRTY_DATASYNC))
>
> Ehh.
>
> Why not just lock the inode around the thing?
>
> The above looks rather ugly.
Ok, me again.
The inode->i_state locking is rather nasty: there is no need to lock the
inode. We just have to wait for it to become unlocked, since its
guaranteed that who locked it wrote it to disk. (sync_one())
Aviro suggested the following, which is much cleaner than the previous
patch:
--- fs/inode.c~ Thu Apr 12 21:15:23 2001
+++ fs/inode.c Thu Apr 12 21:16:35 2001
@@ -301,6 +301,8 @@
while (inode->i_state & I_DIRTY)
sync_one(inode, sync);
spin_unlock(&inode_lock);
+ if (sync)
+ wait_on_inode(inode);
}
else
printk("write_inode_now: no super block\n");
@@ -357,6 +359,7 @@
out:
spin_unlock(&inode_lock);
+ wait_on_inode(inode);
return err;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 15 2001 - 21:00:20 EST