From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: panic in do_last()
Date: Fri, 18 Apr 2014 02:57:50 +0100
Message-ID: <20140418015750.GG18016@ZenIV.linux.org.uk>
References: <CAF1ivSYoOvxMg3WjQYH5Jtv3tTY8NUn+QM7SvQWHJ1M1bVCZeg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: David Howells <dhowells@redhat.com>, linux-fsdevel@vger.kernel.org,
	Hugh Dickins <hughd@google.com>
To: Lin Ming <minggr@gmail.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:34540 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751041AbaDRB5x (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 17 Apr 2014 21:57:53 -0400
Content-Disposition: inline
In-Reply-To: <CAF1ivSYoOvxMg3WjQYH5Jtv3tTY8NUn+QM7SvQWHJ1M1bVCZeg@mail.gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Thu, Apr 17, 2014 at 06:14:51PM -0700, Lin Ming wrote:
> Hi Dave,
> 
> I tried to reproduce bug "BUG at mm/filemap.c:202!"
> https://lkml.org/lkml/2014/4/15/577 with the attached programs.
> I can't reproduce it, but it triggered another bug related to commit  b18825a7c.
> 
> commit b18825a7c8e37a7cf6abb97a12a6ad71af160de7
> Author: David Howells <dhowells@redhat.com>
> Date:   Thu Sep 12 19:22:53 2013 +0100
> 
>     VFS: Put a small type field into struct dentry::d_flags
> 
> [  216.673863] BUG: unable to handle kernel NULL pointer dereference
> at           (null)
> [  216.674235] IP: [<ffffffff81108961>] do_last.isra.44+0x7d2/0x9ea

Where is it in do_last()?  Hard to tell without even the hex dump of
oopsing code (and trying to reproduce it here hasn't produced any oopsen
so far).

And your test.c is _really_ weird:

> 		fd = open("/mnt/t.txt", 0666);

Just what is that 0666 doing, in your opinion?  And how is it different
from O_NOCTTY | O_EXCL | O_RDWR (which also makes zero sense)?

And this read() loop is just plain odd - you are leaving it if read(fd, &c, 1)
gives you 0 and proceed to print (uninitialized in that case) value of c...

Anyway, I'd really like to see your .config (or, better yet, disassembly of
do_last) along with the hex dump of oopsing code.  Without that...