Hello,
> 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?
Which kernel was that? We had a similar bug in 2.6.11 kernel but it
should be fixed in 2.6.12. I suppose you get the same BUG if you run
just quotaoff(8), right?
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
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
