Christoph Hellwig <hch@xxxxxxxxxxxxx> writes:
> On Thu, Jul 10, 2008 at 05:39:01PM +1000, Niv Sardi wrote:
>> There is a bug in this, that I can see with the Parent Pointers code
>> going on top of it (that will be posted soon), it is basically calling
>> xfs_attr_set_int_trans() in xfs_create() just before the last
>> commit. For some reason, the first call to xfs_roll_trans (after
>> xfs_bmap_add_attrfork_trans()) will complain about the inode being
>> unlocked after xfs_trans_commit(). I understand I need to call
>> xfs_trans_ihold(ip) on it, but we already do in xfs_create() so I
>> think I must be missing something else??? any ideas ?
> There are multiple ways to deal with inodes linked to transactions.
> In all cases it needs to be linked into the transaction by
> xfs_trans_ijoin, or the opencoded equivalent for a new inode in
Shouldn't the inode already be in the transaction ? we just created it
and added it to the directory ?
xfs_dir_ialloc(tp, dp, ip)
xfs_ialloc(tp, dp, ip)
and it has a i_transp after dir_ialloc.
And is why don't we use ijoin in iget as we copy the exact same code a
few lines later ? (like in )
> Then you can use xfs_trans_ihold to make sure on transaction commit
> the inode reference count is not dropped and the inode is not
> unlocked, or simply grab a reference to the inode and let the
> transaction commit handler unlock it and decrement the reference
> count. The latter is what's used by xfs_create and the former is what
> the attr code does, and as far as I can see the only things what works
> with xfs_attr_rolltrans.
hum, that seemed to work on my UML, shall we require callers to do all
the ihold, ijoin stuff or should we do that (or at least check it) from
the new attr*_trans code ?
Description: Text document