fault when using iget() on XFS file system (2.6.9)

fault when using iget() on XFS file system (2.6.9)

[Scott Baker]

Hello,

I'm working on a kernel module that needs to perform an iget() on an
inode that lies in the XFS file system. Most of the time, this works
fine, but occasionally the iget will cause a fault by jumping to
EIP=0. I traced the fault to where iget calls sb->s_op->read_inode,
and I found that XFS doesn't provide a read_inode function. iget
attempts to call the read_inode operation if the inode's state has the
I_NEW bit set. Thus, the kernel jumps off to nowhere.

The code works flawlessly on an uniprocessor system, but fails
intermittently under smp. This leads me to believe that there's a
race. XFS is probably filling in the inode structure on one cpu while
my module is performing the iget on the other.

Does anyone have a suggestion of where I should go from here?
Modifying XFS or the kernel is out of the question. I can re-implement
iget myself, detect the error condition, and sleep until XFS finishes
filling in the inode, but that seems like a bit of a hack.

Thanks,
Scott

Re: fault when using iget() on XFS file system (2.6.9)

[Al Viro]

On Fri, Sep 22, 2006 at 04:42:41PM -0700, Scott Baker wrote:
> I'm working on a kernel module that needs to perform an iget() on an
> inode that lies in the XFS file system.

Explain why you think you need iget().  It's almost certainly a Bad Idea(tm) -
code outside of filesystem has no business calling it.

Without more context there's no way anyone can help.  What does that
module attempt to do?

Re: fault when using iget() on XFS file system (2.6.9)

[Scott Baker]

> Explain why you think you need iget().  It's almost certainly a Bad Idea(tm) -
> code outside of filesystem has no business calling it.

Hello Al,

Thanks for the reply. I'm working on a file system layering module.
Without going into a whole lot of detail, it needs to sit on top of a
lower file system (such as ext3 or xfs), and presents itself as a file
system to other layers, such as usermode and the kernel nfs server.

The kernel nfs server uses the get_object export_operation to map a
file handle (which in our case is identical an inode number) into a
denty. Thus, the kernel nfsd presents my layer with an inode number,
which I must map into a dentry. I do this by calling iget() on the
lower file system (ext3, xfs) to get the inode, then work from there
to get all of the dentrys stitched together.

Thus, I could make everything work if I had a general-purpose
mechanism for querying the lower file system (xfs, ext3) with an inode
number to get an inode or dentry. I thought iget() was my answer, but
it doesn't work in the general case for xfs.

Scott