Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751858AbcJDRe3 (ORCPT <rfc822;w@1wt.eu>);
        Tue, 4 Oct 2016 13:34:29 -0400
Received: from gum.cmpxchg.org ([85.214.110.215]:57496 "EHLO gum.cmpxchg.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751020AbcJDRe2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 4 Oct 2016 13:34:28 -0400
Date: Tue, 4 Oct 2016 19:34:25 +0200
From: Johannes Weiner <hannes@cmpxchg.org>
To: Dave Jones <davej@codemonkey.org.uk>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Subject: Re: page_cache_tree_insert WARN_ON hit on 4.8+
Message-ID: <20161004173425.GA1223@cmpxchg.org>
References: <20161004170955.n25polpcsotmwcdq@codemonkey.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161004170955.n25polpcsotmwcdq@codemonkey.org.uk>
User-Agent: Mutt/1.7.0 (2016-08-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2020
Lines: 42

Hi Dave,

On Tue, Oct 04, 2016 at 01:09:55PM -0400, Dave Jones wrote:
> Hit this during a trinity run.
> Kernel built from v4.8-1558-g21f54ddae449
> 
> WARNING: CPU: 0 PID: 5670 at ./include/linux/swap.h:276 page_cache_tree_insert+0x198/0x1b0
> CPU: 0 PID: 5670 Comm: trinity-c6 Not tainted 4.8.0-think+ #2
>  ffffc900003a3ab8 ffffffffb03dc311 0000000000000000 0000000000000000
>  ffffffffb0c063d6 ffffffffb018d898 ffffc900003a3af8 ffffffffb008b550
>  00000114003a3b30 ffffffffb0c063d6 0000000000000114 0000000000000000
> Call Trace:
>  [<ffffffffb03dc311>] dump_stack+0x6c/0x9b
>  [<ffffffffb018d898>] ? page_cache_tree_insert+0x198/0x1b0
>  [<ffffffffb008b550>] __warn+0x110/0x130
>  [<ffffffffb008b6dc>] warn_slowpath_null+0x2c/0x40
>  [<ffffffffb018d898>] page_cache_tree_insert+0x198/0x1b0
>  [<ffffffffb01900c4>] __add_to_page_cache_locked+0x1a4/0x3a0
>  [<ffffffffb0190379>] add_to_page_cache_lru+0x79/0x1c0
>  [<ffffffffb0193456>] generic_file_read_iter+0x916/0xce0
>  [<ffffffffb0232090>] do_iter_readv_writev+0x120/0x1c0
>  [<ffffffffb0192b40>] ? wait_on_page_bit_killable+0x100/0x100
>  [<ffffffffb0192b40>] ? wait_on_page_bit_killable+0x100/0x100
>  [<ffffffffb0232e29>] do_readv_writev+0x1f9/0x2e0
>  [<ffffffffb025d44e>] ? __fdget_pos+0x5e/0x70
>  [<ffffffffb025d44e>] ? __fdget_pos+0x5e/0x70
>  [<ffffffffb025d44e>] ? __fdget_pos+0x5e/0x70
>  [<ffffffffb0232f74>] vfs_readv+0x64/0x90
>  [<ffffffffb023300d>] do_readv+0x6d/0x120
>  [<ffffffffb0234907>] SyS_readv+0x27/0x30
>  [<ffffffffb000276f>] do_syscall_64+0x7f/0x200
>  [<ffffffffb09cfa8b>] entry_SYSCALL64_slow_path+0x25/0x25

Thanks for the report.

I've been trying to reproduce this too after Linus got hit by it. Is
there any way to trace back the steps what trinity was doing exactly?
What kind of file(system) this was operating on, file size, what the
/proc/vmstat delta before the operation until the trigger looks like?

The call to WARN() is new, the actual underlying bug could have been
around for a while, making it hard to narrow down.