All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Antonio SJ Musumeci <trapexit@spawn.link>,
	fuse-devel <fuse-devel@lists.sourceforge.net>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [fuse-devel] Kernel panic under load
Date: Fri, 9 Sep 2016 15:42:39 -0400	[thread overview]
Message-ID: <20160909194239.GA16056@cmpxchg.org> (raw)
In-Reply-To: <CAJfpeguMfoK+foKxUeSLOw0aD=U+ya6BgpRm2XnFfKx3w2Nfpg@mail.gmail.com>

Hi Miklos,

On Fri, Sep 09, 2016 at 04:32:49PM +0200, Miklos Szeredi wrote:
> On Fri, Sep 9, 2016 at 3:34 PM, Antonio SJ Musumeci <trapexit@spawn.link> wrote:
> > https://gist.github.com/bauruine/3bc00075c4d0b5b3353071d208ded30f
> > https://github.com/trapexit/mergerfs/issues/295
> >
> > I've some users which are having issues with my filesystem where the
> > system's load increases and then the kernel panics.
> >
> > Has anyone seen this before?
> 
> Quite possibly this is caused by fuse, but the BUG is deep in mm
> territory and I have zero clue about what it means.
> 
> Hannes,  can you please look a the above crash in mm/workingset.c?

The MM maintains a reclaimable list of page cache tree nodes that have
gone empty (all pages evicted) except for the shadow entries reclaimed
pages leave behind. When faulting a regular page back into such a node
the code in page_cache_tree_insert() removes it from the list again:

		workingset_node_pages_inc(node);
		/*
		 * Don't track node that contains actual pages.
		 *
		 * Avoid acquiring the list_lru lock if already
		 * untracked.  The list_empty() test is safe as
		 * node->private_list is protected by
		 * mapping->tree_lock.
		 */
		if (!list_empty(&node->private_list))
			list_lru_del(&workingset_shadow_nodes,
				     &node->private_list);

The BUG_ON() triggers when we later walk the reclaimable list and find
a radix tree node that has actual pages in it. This could happen when
pages are inserted into a mapping without using add_to_page_cache and
related functions. Does that maybe ring a bell?

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Antonio SJ Musumeci <trapexit@spawn.link>,
	fuse-devel <fuse-devel@lists.sourceforge.net>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [fuse-devel] Kernel panic under load
Date: Fri, 9 Sep 2016 15:42:39 -0400	[thread overview]
Message-ID: <20160909194239.GA16056@cmpxchg.org> (raw)
In-Reply-To: <CAJfpeguMfoK+foKxUeSLOw0aD=U+ya6BgpRm2XnFfKx3w2Nfpg@mail.gmail.com>

Hi Miklos,

On Fri, Sep 09, 2016 at 04:32:49PM +0200, Miklos Szeredi wrote:
> On Fri, Sep 9, 2016 at 3:34 PM, Antonio SJ Musumeci <trapexit@spawn.link> wrote:
> > https://gist.github.com/bauruine/3bc00075c4d0b5b3353071d208ded30f
> > https://github.com/trapexit/mergerfs/issues/295
> >
> > I've some users which are having issues with my filesystem where the
> > system's load increases and then the kernel panics.
> >
> > Has anyone seen this before?
> 
> Quite possibly this is caused by fuse, but the BUG is deep in mm
> territory and I have zero clue about what it means.
> 
> Hannes,  can you please look a the above crash in mm/workingset.c?

The MM maintains a reclaimable list of page cache tree nodes that have
gone empty (all pages evicted) except for the shadow entries reclaimed
pages leave behind. When faulting a regular page back into such a node
the code in page_cache_tree_insert() removes it from the list again:

		workingset_node_pages_inc(node);
		/*
		 * Don't track node that contains actual pages.
		 *
		 * Avoid acquiring the list_lru lock if already
		 * untracked.  The list_empty() test is safe as
		 * node->private_list is protected by
		 * mapping->tree_lock.
		 */
		if (!list_empty(&node->private_list))
			list_lru_del(&workingset_shadow_nodes,
				     &node->private_list);

The BUG_ON() triggers when we later walk the reclaimable list and find
a radix tree node that has actual pages in it. This could happen when
pages are inserted into a mapping without using add_to_page_cache and
related functions. Does that maybe ring a bell?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-09-09 19:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAB3-ZyQ4Mbj2g6b6Zt4pGLhE7ew9O==rNbUgAaPLYSwdRK3Czw@mail.gmail.com>
2016-09-09 14:32 ` [fuse-devel] Kernel panic under load Miklos Szeredi
2016-09-09 14:32   ` Miklos Szeredi
2016-09-09 19:42   ` Johannes Weiner [this message]
2016-09-09 19:42     ` Johannes Weiner
2016-09-13  8:42     ` Miklos Szeredi
2016-09-13  8:42       ` Miklos Szeredi
2016-09-14 14:31       ` Johannes Weiner
2016-09-14 14:31         ` Johannes Weiner
2016-09-14 14:51         ` Antonio SJ Musumeci
2016-09-21  8:54           ` Miklos Szeredi
2016-09-21  8:54             ` Miklos Szeredi

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=20160909194239.GA16056@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=trapexit@spawn.link \
    /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.