Hi,
On Fri, 2005-07-08 at 14:58, Stephen Smalley wrote:
> This patch modifies ext3 to call the inode_init_security LSM hook to
> obtain the security attribute for a newly created inode and to set the
> resulting attribute on the new inode as part of the same transaction.
> This parallels the existing processing for setting ACLs on newly
> created inodes.
>
> Please let me know if you have any comments or suggestions for improvement.
> + err = ext3_init_security(handle,inode, dir);
> + if (err) {
> + DQUOT_FREE_INODE(inode);
> + goto fail2;
> + }
This looks fine but it lead me to something else...
I wanted to just double-check that the above code gets the inode cleanup
right if we get EDQUOT when allocating the EA block during inode
initialisation. I tried it with the equivalent ACL block of code, not
actually using SELinux, and it worked as expected (set a default ACL on
a directory, set quota to prevent further block allocations, and try to
allocate a new inode; you get EDQUOT back.)
Trouble is, on unmounting the fs I got a
Kernel BUG at "fs/dquot.c":422
in invalidate_dquots:
#ifdef __DQUOT_PARANOIA
if (atomic_read(&dquot->dq_count))
BUG();
#endif
backtrace
RIP: 0010:[<ffffffff801a62e0>] <ffffffff801a62e0>{vfs_quota_off+512}
Call Trace:<ffffffff80190ed5>{sys_umount+533} <ffffffff8010f31d>{error_exit+0}
<ffffffff8010e99e>{system_call+126}
It seems repeatable to me --- it hit twice out of two attempts. Jan,
recognise this problem?
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
