From: Christoph Hellwig <hch@infradead.org>
To: Eric Paris <eparis@parisplace.org>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-security-module@vger.kernel.org,
Chandra Seetharaman <sekharan@us.ibm.com>,
XFS Mailing List <xfs@oss.sgi.com>
Subject: Re: Occasional memory fault in inode_has_perm() while running xfstest 234
Date: Mon, 14 Nov 2011 15:20:44 -0500 [thread overview]
Message-ID: <20111114202044.GA306@infradead.org> (raw)
In-Reply-To: <CACLa4psaXKWT0uQBdQFTkT6bzqLED1dZna5RhBK3-oZ=6LjDRw@mail.gmail.com>
On Mon, Nov 14, 2011 at 10:13:11AM -0500, Eric Paris wrote:
> The only way this can happen is if the filesystem is creating inodes
> and not calling security_inode_alloc() (which should be done in
> inode_init_always)
>
> I can only guess (and believe me it is a complete wild guess after
> looking at grep for 5 seconds) it has something to do with the XFS
> __releases() function which does some weirdness in the case of a
> failed call to inode_init_always().
Do you mean xfs_iget_cache_hit?
> The only other option is an FS somehow still uses an inode after
> __destroy_inode(), but I'd assume that would land you in other
> troubles. In either case, I'm hard pressed to blame SELinux/LSM,
> since the VFS does appear to be hooked in the right places
> (inode_init_alwasys and __destroy_inode) to set and unset
> inode->i_security....
XFS inodes have a longer life time than VFS inodes they still
hang around after ->destroy_inode, and if we manage to reuse them
we'll call inode_init_always on them manually. The error handling
there is nasty - basically we try to move it back into the state
before we tried to reuse it, return an error to userspace and then
expect the inode to either get reclaimed, or that we have enough
memory next time someone tries to reuse it. Note that the only
way for it to fail is if security_inode_alloc fails, so on normal
non-LSM systems it won't ever fail.
I can't really see an issue with i_security lifetimes from a quick
look over the code, though.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-11-14 20:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-10 21:36 Occasional memory fault in inode_has_perm() while running xfstest 234 Chandra Seetharaman
2011-11-14 10:27 ` Christoph Hellwig
2011-11-14 15:13 ` Eric Paris
2011-11-14 20:20 ` Christoph Hellwig [this message]
2011-11-14 21:55 ` Chandra Seetharaman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111114202044.GA306@infradead.org \
--to=hch@infradead.org \
--cc=eparis@parisplace.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sekharan@us.ibm.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox