xfs
[Top] [All Lists]

Re: [RFC] libxfs: adding attribute fork frees xfs_inode ptr

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: [RFC] libxfs: adding attribute fork frees xfs_inode ptr
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 24 Apr 2014 08:22:15 +1000
Cc: XFS Mailing List <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140423210445.700477624@xxxxxxx>
References: <20140423210034.892939354@xxxxxxx> <20140423210445.700477624@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Apr 23, 2014 at 04:04:35PM -0500, Mark Tinguely wrote:
> User space does not currently perform any attribute adding/deleting,
> but if we do want to fix attributes or use them for parent inode
> pointers, user space should support attributes.
> 
> The adding an attribute fork is done in an embedded transaction
> inside xfs_attr_set_int(). The xfs_trans_commit in xfs_bmap_add_attrfork()
> will free the xfs_inode pointer causing xfs_attr_calc_size() in
> xfs_attr_set_int() to fail.

It shouldn't. xfs_bmap_add_attrfork() does:

        xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL);

which in the kernel code sets:

        iip->ili_lock_flags = lock_flags;


The libxfs code doesn't do that, so when xfs_trans_commit() gets
to inode_item_unlock():


        if (!iip->ili_lock_flags)
                libxfs_iput(ip, 0);
        else
                iip->ili_lock_flags = 0;

It frees the inode rather than just returning it with the lock
flags cleared.

Note that libxfs still has libxfs_trans_ijoin_ref() which sets the
lock flags, but this has been removed from the kernel code. IOWs,
this is a libxfs/trans.c::xfs_trans_ijoin() bug, not something that
needs fixing in the shared kernel/user libxfs code.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>