public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dipankar Sarma <dipankar@in.ibm.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: John M Flinchbaugh <glynis@butterfly.hjsoft.com>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@transmeta.com>,
	Maneesh Soni <maneesh@in.ibm.com>
Subject: Re: 2.5.70-bk16: nfs crash
Date: Fri, 13 Jun 2003 12:24:19 +0530	[thread overview]
Message-ID: <20030613065418.GC1331@in.ibm.com> (raw)
In-Reply-To: <16105.27531.983439.972077@charged.uio.no>

On Thu, Jun 12, 2003 at 11:13:31PM -0700, Trond Myklebust wrote:
> >>>>> " " == Dipankar Sarma <dipankar@in.ibm.com> writes:
> d_lookup() is the only place where someone can pick up an existing
> dentry for which they do not already hold a reference.

AFAICS, the way to do a perfectly safe "sole ownership" check is
to grab the per-dentry lock (instead of dcache_lock) and
do the check.

>     >> d_invalidate(), d_prune_aliases(), prune_dcache(),
>     >> shrink_dcache_sb() are but a few functions that rely on the
>     >> above code snippet working to keep d_lookup() from intruding.
> 
>      > Those routines hold the per-dentry lock as required and that
>      > protects them from intruding lockfree d_lookup().
> 
> d_invalidate() does not. d_prune_aliases() does not. d_unhash() does
> not.
> 
> Down in the per-filesystem code, I know of several locations in the
> NFS code that do not. There's one in procfs. I'm sure you can find
> more examples in the other filesystems too...

Yes and we need an audit. Besides I see places where d_count check
is being done without holding *any* lock. That is ok only if the
dentry is guranteed to be unhashed and we are doing a "sole ownership"
check. Otherwise it may not work.

> 
> Your argument only holds water if you demand that all callers of
> d_drop() should also take the per-dentry lock. AFAICS this is not
> being enforced.

There are some rules that we need to work out irrespective of
RCU and document clearly -

1. d_unhashed() checks that are being done with and without dcache_lock -

	if (!d_unhashed(new_dentry)) {
		d_drop(new_dentry);
		rehash = new_dentry;
	}
This seems to require that either we hold the dcache_lock or the operations
that we do on the dentry allow unhashed dentries.

2. Checking for "sole ownership" of dentries. Depending on whether the
   dentry is hashed and what operation we are going to do, we will
   need to hold the per-dentry lock.

I am glad that you are reviewing this. Is there any other dcache
operations in filesystems that you would like to add to the list
above ?

Thanks
Dipankar

  reply	other threads:[~2003-06-13  6:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-12 12:56 2.5.70-bk16: nfs crash John M Flinchbaugh
2003-06-12 13:52 ` Dipankar Sarma
2003-06-12 15:33   ` Dipankar Sarma
2003-06-12 15:35   ` Trond Myklebust
2003-06-12 15:53     ` Dipankar Sarma
2003-06-12 16:26       ` Trond Myklebust
2003-06-12 16:49         ` Linus Torvalds
2003-06-12 16:55           ` Linus Torvalds
2003-06-12 19:53         ` Dipankar Sarma
2003-06-13  5:24           ` Trond Myklebust
2003-06-13  5:50             ` Dipankar Sarma
2003-06-13  6:13               ` Trond Myklebust
2003-06-13  6:54                 ` Dipankar Sarma [this message]
2003-06-13  6:06             ` Dipankar Sarma
2003-06-12 16:30       ` viro
2003-06-12 16:55         ` Dipankar Sarma
2003-06-12 15:49   ` Linus Torvalds
2003-06-12 16:05     ` Dipankar Sarma
2003-06-12 16:18     ` Linus Torvalds
2003-06-12 16:35       ` Dipankar Sarma
2003-06-12 16:47         ` Linus Torvalds
2003-06-13 12:48       ` Maneesh Soni

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=20030613065418.GC1331@in.ibm.com \
    --to=dipankar@in.ibm.com \
    --cc=glynis@butterfly.hjsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maneesh@in.ibm.com \
    --cc=torvalds@transmeta.com \
    --cc=trond.myklebust@fys.uio.no \
    /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