linux-kernel - fault when using iget() on XFS file system (2.6.9)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Sep 2006 16:42:41 -0700
From:	"Scott Baker" <smbaker@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: fault when using iget() on XFS file system (2.6.9)

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/