public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Peter Klotz <peter.klotz@aon.at>,
	Roman Kononov <kernel@kononov.ftml.net>,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: BUG: soft lockup - is this XFS problem?
Date: Mon, 5 Jan 2009 02:48:21 +0100	[thread overview]
Message-ID: <20090105014821.GA367@wotan.suse.de> (raw)
In-Reply-To: <20090103214443.GA6612@infradead.org>

On Sat, Jan 03, 2009 at 04:44:43PM -0500, Christoph Hellwig wrote:
> On Tue, Dec 30, 2008 at 05:23:33AM +0100, Nick Piggin wrote:
> > On Tue, Dec 23, 2008 at 12:12:59PM -0500, Christoph Hellwig wrote:
> > > 
> > > Nick, I've seen various reports like this by Roman.  It seems to be
> > > caused by an interaction of the lockless pagecache with the xfs
> > > I/O code.  Any idea what might be wrong here:
> > 
> > Hmm, it could get into a loop here if there is a page in the pagecache
> > with a zero refcount, which might be a problem with XFS... other looping
> > conditions might indicate a problem iwth lockless pagecache or radix
> > tree. It would be very helpful to know what condition it is looping on...
> 
> See http://oss.sgi.com/bugzilla/show_bug.cgi?id=805

OK.. Hmm, well here is a modification to your patch which might help further.
I'll see if I can reproduce it here meanwhile.

---
 mm/filemap.c |   29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

Index: linux-2.6/mm/filemap.c
===================================================================
--- linux-2.6.orig/mm/filemap.c
+++ linux-2.6/mm/filemap.c
@@ -770,11 +770,13 @@ EXPORT_SYMBOL(find_or_create_page);
  * find_get_pages() returns the number of pages which were found.
  */
 unsigned find_get_pages(struct address_space *mapping, pgoff_t start,
-			    unsigned int nr_pages, struct page **pages)
+			    unsigned int nr_pages,
+			    struct page **pages)
 {
 	unsigned int i;
 	unsigned int ret;
 	unsigned int nr_found;
+	int locked = 0;
 
 	rcu_read_lock();
 restart:
@@ -785,27 +787,46 @@ restart:
 		struct page *page;
 repeat:
 		page = radix_tree_deref_slot((void **)pages[i]);
-		if (unlikely(!page))
+		if (unlikely(!page)) {
+			if (printk_ratelimit())
+				printk(KERN_INFO "unable to deref page\n");
 			continue;
+		}
+
 		/*
 		 * this can only trigger if nr_found == 1, making livelock
 		 * a non issue.
 		 */
-		if (unlikely(page == RADIX_TREE_RETRY))
+		if (unlikely(page == RADIX_TREE_RETRY)) {
+			printk(KERN_INFO "got RADIX_TREE_RETRY\n");
 			goto restart;
+		}
 
-		if (!page_cache_get_speculative(page))
+		if (!page_cache_get_speculative(page)) {
+			/* If the page is in the radix-tree, and the radix-tree
+			 * is locked, the page must have a non-zero refcount */
+			BUG_ON(locked);
+			printk(KERN_INFO "page_cache_get failed\n");
+			spin_lock_irq(&mapping->tree_lock);
+			locked = 1;
 			goto repeat;
+		}
 
 		/* Has the page moved? */
 		if (unlikely(page != *((void **)pages[i]))) {
+			BUG_ON(locked);
+			printk(KERN_INFO "page moved\n");
 			page_cache_release(page);
+			spin_lock_irq(&mapping->tree_lock);
+			locked = 1;
 			goto repeat;
 		}
 
 		pages[ret] = page;
 		ret++;
 	}
+	if (locked)
+		spin_unlock_irq(&mapping->tree_lock);
 	rcu_read_unlock();
 	return ret;
 }

  reply	other threads:[~2009-01-05  1:48 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-19  6:59 BUG: soft lockup - is this XFS problem? Roman Kononov
2008-12-23 17:12 ` Christoph Hellwig
2008-12-30  4:23   ` Nick Piggin
2009-01-03 21:44     ` Christoph Hellwig
2009-01-05  1:48       ` Nick Piggin [this message]
2009-01-05  4:19         ` Nick Piggin
2009-01-05  6:48           ` Nick Piggin
2009-01-05 14:25             ` Roman Kononov
2009-01-05 16:21             ` Peter Klotz
2009-01-05 16:41               ` [patch] mm: fix lockless pagecache reordering bug (was Re: BUG: soft lockup - is this XFS problem?) Nick Piggin
2009-01-05 17:30                 ` Linus Torvalds
2009-01-05 18:00                   ` Nick Piggin
2009-01-05 18:44                     ` Linus Torvalds
2009-01-05 19:39                       ` Linus Torvalds
2009-01-06 17:17                         ` Paul E. McKenney
2009-01-05 20:12                       ` Paul E. McKenney
2009-01-05 20:39                         ` Linus Torvalds
2009-01-05 21:57                           ` Paul E. McKenney
2009-01-06  2:05                             ` Nick Piggin
2009-01-06  2:23                               ` Paul E. McKenney
2009-01-06  2:29                               ` Linus Torvalds
2009-01-06  8:38                               ` Peter Klotz
2009-01-06  8:43                                 ` Nick Piggin
2009-01-06 16:16                               ` Roman Kononov
2009-01-05 21:04                         ` [patch] mm: fix lockless pagecache reordering bug (was Peter Zijlstra
2009-01-05 21:58                           ` Paul E. McKenney
2011-07-14 11:23             ` BUG: soft lockup - is this XFS problem? Guus Sliepen
2011-07-14 18:03               ` Peter Klotz
2011-07-14 19:29                 ` Guus Sliepen

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=20090105014821.GA367@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=hch@infradead.org \
    --cc=kernel@kononov.ftml.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.klotz@aon.at \
    --cc=xfs@oss.sgi.com \
    /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