From: john stultz <johnstul@us.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Nick Piggin <npiggin@suse.de>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
John Kacur <jkacur@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [patch 11/33] fs: dcache scale subdirs
Date: Mon, 21 Jun 2010 23:02:37 -0700 [thread overview]
Message-ID: <1277186557.1791.7.camel@work-vm> (raw)
In-Reply-To: <1277132103.1875.519.camel@laptop>
On Mon, 2010-06-21 at 16:55 +0200, Peter Zijlstra wrote:
> On Tue, 2010-06-22 at 00:48 +1000, Nick Piggin wrote:
> > > Right, so I was staring at the -rt splat, so its John who created that
> > > wreckage?
> >
> > It was, but apparently they saw an RCU bug there somewhere and hit it
> > with the big hammer. I haven't been able to reproduce it on a non-rt
> > kernel yet, and I see yet why RCU is not good enough here.
>
> John, could you describe the failure you spotted?
The problem was that the rcu_read_lock() on the dentry ascending wasn't
preventing d_put/d_kill from removing entries from the parent node. So
the next entry we tried to follow was invalid. So we were getting odd
oopses from select_parent().
I'm not as familiar with the rcu rules there, so the patch I made just
held the locks as it went down the chain. Not ideal of course, but still
an improvement over the dcache_lock that was there prior.
Peter: I'm sorry, I've been out for a few days. Can you give me some
background on what brought this up and what -rt splat you mean?
thanks
-john
next prev parent reply other threads:[~2010-06-22 6:02 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-04 6:51 [patch 00/33] my current vfs scalability patch queue npiggin
2009-09-04 6:51 ` [patch 01/33] fs: no games with DCACHE_UNHASHED npiggin
2009-09-04 6:51 ` [patch 02/33] fs: cleanup files_lock npiggin
2009-09-04 6:51 ` [patch 03/33] fs: scale files_lock npiggin
2009-09-28 13:22 ` Peter Zijlstra
2009-09-28 13:24 ` Peter Zijlstra
2009-10-01 2:16 ` Nick Piggin
[not found] ` <r2i3282373b1004011751j440635b3n484018db2e2bc50c@mail.gmail.com>
2010-04-02 2:24 ` [patch 1/2] fs: cleanup files_lock tim
2009-09-04 6:51 ` [patch 04/33] fs: brlock vfsmount_lock npiggin
2009-09-04 15:19 ` Jens Axboe
2009-09-07 7:39 ` Nick Piggin
2009-09-22 15:17 ` Al Viro
2009-09-27 19:56 ` Nick Piggin
2009-09-28 13:21 ` Peter Zijlstra
2009-10-01 2:10 ` Nick Piggin
2009-09-04 6:51 ` [patch 05/33] fs: scale mntget/mntput npiggin
2009-09-07 9:41 ` Nick Piggin
2009-09-04 6:51 ` [patch 06/33] fs: dcache scale hash npiggin
2009-09-04 6:51 ` [patch 07/33] fs: dcache scale lru npiggin
2009-09-04 6:51 ` [patch 08/33] fs: dcache scale nr_dentry npiggin
2009-09-04 14:41 ` Daniel Walker
2009-09-07 7:36 ` Nick Piggin
2009-09-04 6:51 ` [patch 09/33] fs: dcache scale dentry refcount npiggin
2009-09-06 18:01 ` Eric Paris
2009-09-07 7:44 ` Nick Piggin
2009-09-07 11:21 ` Eric Paris
2009-09-07 11:35 ` Nick Piggin
2009-09-04 6:51 ` [patch 10/33] fs: dcache scale d_unhashed npiggin
2009-09-04 6:51 ` [patch 11/33] fs: dcache scale subdirs npiggin
2010-06-17 15:13 ` Peter Zijlstra
2010-06-17 16:53 ` Nick Piggin
2010-06-21 13:35 ` Peter Zijlstra
2010-06-21 14:48 ` Nick Piggin
2010-06-21 14:55 ` Peter Zijlstra
2010-06-22 6:02 ` john stultz [this message]
2010-06-22 6:06 ` Nick Piggin
2010-06-22 7:27 ` Peter Zijlstra
2010-06-23 2:03 ` john stultz
2010-06-23 7:23 ` Peter Zijlstra
2009-09-04 6:51 ` [patch 12/33] fs: scale inode alias list npiggin
2009-09-04 6:51 ` [patch 13/33] fs: use RCU / seqlock logic for reverse and multi-step operaitons npiggin
2009-09-04 6:51 ` [patch 14/33] fs: dcache remove dcache_lock npiggin
2009-09-04 6:51 ` [patch 15/33] fs: dcache reduce dput locking npiggin
2009-09-04 6:51 ` [patch 16/33] fs: dcache per-bucket dcache hash locking npiggin
2009-09-04 14:51 ` Daniel Walker
2009-09-07 7:38 ` Nick Piggin
2009-09-04 6:51 ` [patch 17/33] fs: dcache reduce dcache_inode_lock npiggin
2009-09-04 6:51 ` [patch 18/33] fs: dcache per-inode inode alias locking npiggin
2009-09-04 6:52 ` [patch 19/33] fs: icache lock s_inodes list npiggin
2009-09-04 6:52 ` [patch 20/33] fs: icache lock inode hash npiggin
2009-09-04 6:52 ` [patch 21/33] fs: icache lock i_state npiggin
2009-09-04 6:52 ` [patch 22/33] fs: icache lock i_count npiggin
2009-09-04 6:52 ` [patch 23/33] fs: icache atomic inodes_stat npiggin
2009-09-04 6:52 ` [patch 24/33] fs: icache lock lru/writeback lists npiggin
2009-09-04 6:52 ` [patch 25/33] fs: icache protect inode state npiggin
2009-09-04 6:52 ` [patch 26/33] fs: inode atomic last_ino, iunique lock npiggin
2009-09-04 6:52 ` [patch 27/33] fs: icache remove inode_lock npiggin
2009-09-04 6:52 ` [patch 28/33] fs: inode factor hash lock into functions npiggin
2009-09-04 6:52 ` [patch 29/33] Remove the global inode_hash_lock and replace it with per-hash-bucket locks. fs: inode per-bucket inode hash locks npiggin
2009-09-04 7:05 ` Nick Piggin
2009-09-04 6:52 ` [patch 30/33] fs: inode lazy lru npiggin
2009-09-04 6:52 ` [patch 31/33] fs: RCU free inodes npiggin
2009-09-04 6:52 ` [patch 32/33] fs: rcu walk for i_sb_list npiggin
2009-09-04 6:52 ` [patch 33/33] fs: improve scalability of pseudo filesystems npiggin
2009-09-04 7:05 ` [patch 00/33] my current vfs scalability patch queue Nick Piggin
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=1277186557.1791.7.camel@work-vm \
--to=johnstul@us.ibm.com \
--cc=jkacur@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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).