On Mon, May 25, 2015 at 09:41:04AM -0500, Anthony Plack wrote:
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -117,6 +117,10 @@ static int btrfs_init_inode_security(struct btrfs_trans_handle *trans,
> err = btrfs_init_acl(trans, inode, dir);
> if (!err)
> err = btrfs_xattr_security_init(trans, inode, dir, qstr);
In this example, I think that the additional pr_debug does not help.
btrfs_xattr_security_init is a smple wrapper around the generic function
security_inode_init_security so basically all errors are not from btrfs
but the sercurity subsystem.
And this has either its own way to report problems or the error code is
returned back to userspace. In this case its create, mknod or mkdir (ie.
the callers of btrfs_xattr_security_init).
> + if (err)
> + pr_debug("BTRFS: Unable to init xattr security. error=%d,transid=%d,inode=%d,dir=%d,qstr=%s", err, trans->transid, inode->i_uid, dir->i_uid, qstr->name);
- error is returned back to userspace,
- transid is not IMHO interesing as we're probably not going to use it
to compare to any past or future transid
- uid/gid and name should be put into the security context, that's out
of btrfs reach
I think it would be better to first start in functions that are part of
the user interface and somehow specific to btrfs (ie. the ioctls).
Another tip is to enhance debugging in some specific subsystem of btrfs.
The existing example is enospc. At the moment I don't have 100% sure
pointers so we might need a few more rounds.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
