Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Anthony Plack <anthony@plack.net>
Cc: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: Log the error conditions to determine which caused the error in btrfs_init_inode_security
Date: Tue, 26 May 2015 15:18:29 +0200	[thread overview]
Message-ID: <20150526131829.GI23255@twin.jikos.cz> (raw)
In-Reply-To: <8C081E15-B762-43C0-A65B-6D7D15983DC9@plack.net>

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.

      reply	other threads:[~2015-05-26 13:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-25  2:42 Additional Debug and other various pr_ additions Anthony Plack
2015-05-25 12:57 ` David Sterba
2015-05-25 14:41   ` [PATCH] Btrfs: Log the error conditions to determine which caused the error in btrfs_init_inode_security Anthony Plack
2015-05-26 13:18     ` David Sterba [this message]

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=20150526131829.GI23255@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=anthony@plack.net \
    --cc=linux-btrfs@vger.kernel.org \
    /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