[Top] [All Lists]

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

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [RFC] libxfs: adding attribute fork frees xfs_inode ptr
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Thu, 24 Apr 2014 15:59:32 -0500
Cc: XFS Mailing List <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <535945DC.6010108@xxxxxxx>
References: <20140423210034.892939354@xxxxxxx> <20140423210445.700477624@xxxxxxx> <20140423222215.GT18672@dastard> <535945DC.6010108@xxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 04/24/14 12:11, Mark Tinguely wrote:
On 04/23/14 17:22, Dave Chinner wrote:
On Wed, Apr 23, 2014 at 04:04:35PM -0500, Mark Tinguely wrote:


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.



nod. That is the correct thing to do.

Since the shared user/kernel code will no longer do a xfs_trans_ihold(),
the libxfs_iput() should be factored out out of inode_item_unlock() and
have the creator release the inode pointer when it is appropriate.

No one besides me is using this so it can go into the next release of


PS. I may not have been very clear, the libxfs_trans_roll() and
    inode_item_done() also cause a premature libxfs_iput().
    Let me do more testing making any changes and target this for


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