All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Trond Myklebust
	<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
Cc: "J. R. Okajima"
	<hooanon05-/E1597aS9LR3+QwDJ9on6Q@public.gmane.org>,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux Filesystem Development
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: 2.6.38-rc2... NFS sillyrename is broken...
Date: Thu, 27 Jan 2011 10:50:27 +1100	[thread overview]
Message-ID: <AANLkTik2JJt4vcX8mMJmz+uwJU01vpMwF0UjQ+3QFAtp@mail.gmail.com> (raw)
In-Reply-To: <1296074585.7127.33.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>

On Thu, Jan 27, 2011 at 7:43 AM, Trond Myklebust
<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org> wrote:
> On Wed, 2011-01-26 at 15:14 -0500, Trond Myklebust wrote:
>> The alternative would be to add a callback that can be called after
>> dentry_iput() if DCACHE_NFSFS_RENAMED is true, and that takes the parent
>> and (negative) dentry as the arguments.
>> sillyrename doesn't need the inode as an argument, but it definitely
>> needs the parent dentry so that it can check for races with
>> ->lookup()...
>
> The following (compile tested only!) patch illustrates what I mean.

We could do this. CEPH also want a way to get d_parent in the inode
unlink path.

I think I can actually check for dentry->d_count == 0 rather than
dentry->d_parent == NULL here, and avoid clearing d_parent
entirely. That might be the better solution for 2.6.38, because other
code I've missed might be expecting to use d_parent.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@gmail.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: "J. R. Okajima" <hooanon05@yahoo.co.jp>,
	linux-nfs@vger.kernel.org,
	Linux Filesystem Development <linux-fsdevel@vger.kernel.org>
Subject: Re: 2.6.38-rc2... NFS sillyrename is broken...
Date: Thu, 27 Jan 2011 10:50:27 +1100	[thread overview]
Message-ID: <AANLkTik2JJt4vcX8mMJmz+uwJU01vpMwF0UjQ+3QFAtp@mail.gmail.com> (raw)
In-Reply-To: <1296074585.7127.33.camel@heimdal.trondhjem.org>

On Thu, Jan 27, 2011 at 7:43 AM, Trond Myklebust
<Trond.Myklebust@netapp.com> wrote:
> On Wed, 2011-01-26 at 15:14 -0500, Trond Myklebust wrote:
>> The alternative would be to add a callback that can be called after
>> dentry_iput() if DCACHE_NFSFS_RENAMED is true, and that takes the parent
>> and (negative) dentry as the arguments.
>> sillyrename doesn't need the inode as an argument, but it definitely
>> needs the parent dentry so that it can check for races with
>> ->lookup()...
>
> The following (compile tested only!) patch illustrates what I mean.

We could do this. CEPH also want a way to get d_parent in the inode
unlink path.

I think I can actually check for dentry->d_count == 0 rather than
dentry->d_parent == NULL here, and avoid clearing d_parent
entirely. That might be the better solution for 2.6.38, because other
code I've missed might be expecting to use d_parent.

  parent reply	other threads:[~2011-01-26 23:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-25 23:30 2.6.38-rc2... NFS sillyrename is broken Trond Myklebust
2011-01-26  8:20 ` J. R. Okajima
2011-01-26 20:14   ` Trond Myklebust
2011-01-26 20:43     ` Trond Myklebust
2011-01-26 20:43       ` Trond Myklebust
     [not found]       ` <1296074585.7127.33.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2011-01-26 23:50         ` Nick Piggin [this message]
2011-01-26 23:50           ` Nick Piggin
2011-01-26 23:59           ` Trond Myklebust
     [not found]             ` <1296086349.7127.55.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2011-01-27  0:44               ` Nick Piggin
2011-01-27  0:44                 ` Nick Piggin
     [not found]                 ` <AANLkTim1-dwNjTpyCi5qBjCer5vgPo4qSNfK7Htd_vfL-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-01-27  0:57                   ` Trond Myklebust
2011-01-27  0:57                     ` Trond Myklebust
     [not found]                     ` <1296089830.25999.1.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2011-01-27  1:25                       ` Nick Piggin
2011-01-27  1:25                         ` Nick Piggin
     [not found]                         ` <AANLkTim_JrZkD_D8HWXNr0qxjQ-=LKaAvzcH_w7A_T42-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-03-05 13:49                           ` Jeff Layton
2011-03-05 13:49                             ` Jeff Layton

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=AANLkTik2JJt4vcX8mMJmz+uwJU01vpMwF0UjQ+3QFAtp@mail.gmail.com \
    --to=npiggin-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org \
    --cc=hooanon05-/E1597aS9LR3+QwDJ9on6Q@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.