From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752207AbcBVRXS (ORCPT <rfc822;w@1wt.eu>);
	Mon, 22 Feb 2016 12:23:18 -0500
Received: from zeniv.linux.org.uk ([195.92.253.2]:45179 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750731AbcBVRXR (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 22 Feb 2016 12:23:17 -0500
Date: Mon, 22 Feb 2016 17:23:14 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= <mic@digikod.net>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        syzkaller <syzkaller@googlegroups.com>,
        Kostya Serebryany <kcc@google.com>,
        Alexander Potapenko <glider@google.com>,
        Sasha Levin <sasha.levin@oracle.com>
Subject: Re: fs: NULL deref in atime_needs_update
Message-ID: <20160222172314.GL17997@ZenIV.linux.org.uk>
References: <CACT4Y+ae=DQjrTtwSqm1PJ9rsnRAvKiBkRjBqaQH6f6W1dOh2Q@mail.gmail.com>
 <56C3B35E.6020109@digikod.net>
 <CACT4Y+YOnDbgo2tEp8BxPy20awzcJ7x0Vw=phDGQ3sUMaE7RvA@mail.gmail.com>
 <20160220032127.GA19926@ZenIV.linux.org.uk>
 <20160220035442.GE17997@ZenIV.linux.org.uk>
 <56C86954.6030101@digikod.net>
 <20160220171044.GH17997@ZenIV.linux.org.uk>
 <CACT4Y+YtSpsFJSg393wjF8e5Ytv6CSH7b=X16UDSZsuniiV3fQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACT4Y+YtSpsFJSg393wjF8e5Ytv6CSH7b=X16UDSZsuniiV3fQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 22, 2016 at 12:20:30PM +0100, Dmitry Vyukov wrote:

> I've reproduced the second report (the one originating in openat) with
> this patch and the WARNING did _not_ fire:

Lovely...  Could you dump your inode.o on anonftp somewhere?  Or post
the disassembled atime_needs_update, for that matter - shouldn't be
all that long...  .config (and gcc version) you are using would also be nice.

On the face of it, NULL inode is a plausible source of that one, but
it's _very_ odd.  It would have to be NULL ->link_inode, and since the
warning hadn't triggered, there was a successful should_follow_link(),
with NULL inode argument.

	Could you slap WARN_ON(!inode) in pick_link()?  Or even
WARN_ON(IS_ERR_OR_NULL(inode)), for that matter...