Re: XFS regression?

["Bhagi rathi" <jahnu77@xxxxxxxxx>]

Thanks Dave for the response.   Thinking futher, why is that xfs_iunpin has
to mark the inode dirty?
All transactions generally modify one time or other, xfs_ichgtime takes care
of marking inode as
dirty. I am thinking on why we need to mark the inode dirty at all, either
in the context of  unpin or
in the context for formatting the inode.

-Bhagi.

On 10/15/07, David Chinner <dgc@xxxxxxx> wrote:
>
> On Sat, Oct 13, 2007 at 07:05:17PM +0530, Bhagi rathi wrote:
> > David, Can you let me know the use after free problem? I want to
> understand
> > how the life cycle of linux inode
> > and xfs inode are related to log flush.
>
> Log I/O completion:
>
>   -> xfs_trans_commited
>        -> xfs_iunpin(xfs inode)
>          get linux inode from xfs inode
>           -> mark_inode_dirty_sync(linux inode)
>
> Freeing the linux inode:
>
> clear_inode(linux_inode)
> -> xfs_inactive()
>     -> xfs_trans_commit() (e.g. freeing data associated with unlinked
> inode)
>        -> xfs_ipin()
>     (link between xfs and linux inode broken)
>   linux inode freed
>
> So, in log I/O completion, we can be completing a previous
> transaction at the same time clear_inode() is running, and
> hence in xfs_iunpin() we can race with the freeing of the
> linux inode as xfs_iunpin does not hold any locks.
>
> > Any pointer is also of great help.
>
> /me points at the code.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> Principal Engineer
> SGI Australian Software Group
>


[[HTML alternate version deleted]]