From: David Sterba <dsterba@suse.cz>
To: Mark Fasheh <mfasheh@suse.de>
Cc: Andrew Vagin <avagin@gmail.com>,
Chris Mason <chris.mason@fusionio.com>,
linux-btrfs@vger.kernel.org, kzak@redhat.com, xemul@openvz.org
Subject: Re: btrfs: stat(2) and /proc/pid/maps returns different devices
Date: Thu, 11 Jul 2013 00:26:50 +0200 [thread overview]
Message-ID: <20130710222650.GI25386@suse.cz> (raw)
In-Reply-To: <20130710174545.GS32502@wotan.suse.de>
On Wed, Jul 10, 2013 at 10:45:45AM -0700, Mark Fasheh wrote:
> Well, what do I get when I pretend I don't care any more? The little voice
> in my head says "keep plugging away". Here's another attempt at fixing this
> problem in a sane manner. Basically, this time we're adding a flag to
> s_flags which btrfs sets. Proc will see the flag and call ->getattr().
>
> This compiles, but it needs testing (which I will get to soon). It still has
> a bunch of problems in my honest opinion but maybe if we get something
> acceptable upstream we can work from there.
>
> Also, as Andrew pointed out there's more than one place which is return
> different device than from stat(2) so I probably need to update more sites
> to deal with this.
>
> Does anyone see a problem with this approach?
The approach looks ok to me, the implementation is internal to vfs and
fairly minimal. The bit that bothers me is the name of the flag, it's
completely unobvious what it means.
There are some differences to the linked suse patch:
> +static dev_t proc_get_dev_from_stat(struct inode *inode)
> +{
> + struct dentry *dentry = d_find_any_alias(inode);
This does the dentry -> inode mapping, while originally there was
&file->f_path
passing just the inode to proc_get_dev_from_stat unnecessarily drops the
available information that's about to be retrieved again.
> + struct kstat kstat;
> +
> + if (!dentry)
> + goto out_error;
> + if (inode->i_op->getattr(NULL, dentry, &kstat))
The suse patch calls vfs_getattr that in turn calls
security_inode_getattr(path->mnt, path->dentry);
That would be missing.
Plus checks for presence of the ->getattr operation. Though this is
superfluous with btrfs, I suggest to use vfs_getattr here, which will
fix all of the above.
> + goto out_error_dput;
> +
> + dput(dentry);
> + return kstat.dev;
> +
> +out_error_dput:
> + dput(dentry);
> +out_error:
> + return inode->i_sb->s_dev;
> +}
next prev parent reply other threads:[~2013-07-10 22:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-04 9:51 btrfs: stat(2) and /proc/pid/maps returns different devices Andrew Vagin
2013-07-05 8:06 ` Andrey Wagin
2013-07-08 21:54 ` David Sterba
2013-07-10 16:31 ` Mark Fasheh
2013-07-10 17:45 ` Mark Fasheh
2013-07-10 22:26 ` David Sterba [this message]
2013-07-19 20:51 ` Mark Fasheh
2013-07-31 18:24 ` David Sterba
2013-10-24 10:41 ` Pavel Emelyanov
2013-07-11 21:25 ` Andrew Vagin
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=20130710222650.GI25386@suse.cz \
--to=dsterba@suse.cz \
--cc=avagin@gmail.com \
--cc=chris.mason@fusionio.com \
--cc=kzak@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=mfasheh@suse.de \
--cc=xemul@openvz.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;
as well as URLs for NNTP newsgroup(s).