All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Balaji Rao <balajirrao@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] NFS support for btrfs - v2
Date: Mon, 18 Aug 2008 16:32:30 -0400	[thread overview]
Message-ID: <1219091550.14063.44.camel@think.oraclecorp.com> (raw)
In-Reply-To: <1219090839.3184.436.camel@pmac.infradead.org>

On Mon, 2008-08-18 at 21:20 +0100, David Woodhouse wrote:
> On Mon, 2008-08-18 at 15:47 -0400, Chris Mason wrote:
> > Lets pretend I had put in commments something like the code below.
> > The important part is that directories have only one link, so they
> > have only one backref.
> 
> OK. Now can I rip that code out anyway? The VFS will never call
> btrfs_lookup() for ".." -- not since the 2.2 kernel :)
> 
> I'm still a little confused about precisely what btrfs_search_slot()
> returns when it doesn't find a match -- that's probably where the
> documentation would be more useful.
> 

if btrfs_search_slot returns < 0, there was an error
if btrfs_search_slot returns > 1, path->slots[0] is the spot in the tree
where you'd want to insert the item.

In this case, if path->slots[0] == 0, there are no keys in the tree
smaller than your search key.

If path->slots[0] == btrfs_header_nritems(path->nodes[0]), there are no
items in this node that have a key > than your search key.

> What I have in btrfs_get_parent() is correct, I think -- but could
> probably be simplified to your version, searching for (u64)-1 and then
> not needing to call btrfs_next_leaf().

Yes.

> 
> Something like this?
> 
> (And am I fixing a use-after-free bug by moving that btrfs_free_path()
> down by a line, at the end?)
> 

Most definitely ;)  One comment inline below

> diff --git a/export.c b/export.c
> index 797b4cb..830e87a 100644
> --- a/export.c
> +++ b/export.c
> @@ -156,27 +156,27 @@ static struct dentry *btrfs_get_parent(struct dentry *child)
>  
>  	key.objectid = dir->i_ino;
>  	btrfs_set_key_type(&key, BTRFS_INODE_REF_KEY);
> -	key.offset = 0;
> +	key.offset = (u64)-1;
>  	ret = btrfs_search_slot(NULL, root, &key, path, 0, 0);
> -	BUG_ON(ret == 0);
> -	ret = 0;
>  
>  	leaf = path->nodes[0];
>  	slot = path->slots[0];
> -	nritems = btrfs_header_nritems(leaf);
> -	if (slot >= nritems) {
> -		ret = btrfs_next_leaf(root, path);
> -		if (ret) {
> -			btrfs_free_path(path);
> -			goto out;
> -		}
> -		leaf = path->nodes[0];
> -		slot = path->slots[0];
> +	if (ret < 0 && slot == 0) {

              ^^^^^^^^^^^^^ should be ||, and should set ret to
something bad if slot == 0

> +		btrfs_free_path(path);
> +		goto out;
>  	}
> +	/*
> +	  This will be in the slot _before_ the one that btrfs_search_slot()
> +	   returns. And for some reason which dwmw2 doesn't quite understand,
> +	   that'll definitely be in the same leaf that btrfs_search_slot()
> +	   returned -- even if btrfs_search_slot() had to look in the _next_
> +	   leaf to find the first key which is greater than what we asked for 
> +	*/
> +	slot--;
>  
> +	btrfs_item_key_to_cpu(leaf, &key, slot);
>  	btrfs_free_path(path);
>  
> -	btrfs_item_key_to_cpu(leaf, &key, slot);
>  	if (key.objectid != dir->i_ino || key.type != BTRFS_INODE_REF_KEY)
>  		goto out;
>  
> 
> 

-chris



  reply	other threads:[~2008-08-18 20:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-20 20:31 [PATCH] NFS support for btrfs - v2 Balaji Rao
2008-08-17 11:53 ` David Woodhouse
2008-08-17 12:51   ` Balaji Rao
2008-08-17 12:56     ` David Woodhouse
2008-08-17 13:24       ` Balaji Rao
2008-08-17 13:30         ` David Woodhouse
2008-08-17 14:17           ` David Woodhouse
2008-08-17 16:10             ` [PATCH] rewrite btrfs_readdir() David Woodhouse
2008-08-18 18:46               ` Chris Mason
2008-08-18 19:08                 ` David Woodhouse
2008-08-18 19:24                   ` Chris Mason
2008-08-18 19:32                     ` David Woodhouse
2008-08-17 13:40         ` [PATCH] NFS support for btrfs - v2 David Woodhouse
2008-08-18 19:23           ` Chris Mason
2008-08-18 19:33             ` David Woodhouse
2008-08-18 19:47               ` Chris Mason
2008-08-18 20:20                 ` David Woodhouse
2008-08-18 20:32                   ` Chris Mason [this message]
2008-08-18 21:52                     ` David Woodhouse
2008-08-19 11:54                       ` Chris Mason
2008-08-19 14:49                         ` David Woodhouse
2008-08-19 21:34                           ` David Woodhouse
2008-08-19  0:16                   ` Christoph Hellwig
2008-08-19  0:21                     ` David Woodhouse
2008-08-18 11:51     ` David Woodhouse
2008-08-18 12:10       ` David Woodhouse
2008-08-18 19:15         ` Chris Mason

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=1219091550.14063.44.camel@think.oraclecorp.com \
    --to=chris.mason@oracle.com \
    --cc=balajirrao@gmail.com \
    --cc=dwmw2@infradead.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.