From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stable-owner@vger.kernel.org>
Date: Tue, 12 Jul 2016 01:46:23 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Chunwei Chen <david.chen@osnexus.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] vfs: check i_count under lock in evict_inodes
Message-ID: <20160712004623.GA14480@ZenIV.linux.org.uk>
References: <1468282504-2272-1-git-send-email-david.chen@osnexus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1468282504-2272-1-git-send-email-david.chen@osnexus.com>
Sender: stable-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Mon, Jul 11, 2016 at 05:15:04PM -0700, Chunwei Chen wrote:
> We need to check i_count again with i_lock held, because iput might re-add
> i_count when lazytime is on. Without this check, we could end up with
> double-free or use-after-free.

Details, please.  Ideally - with a reproducer.  Who is calling that iput()
at that point of generic_shutdown_super() (has to be another thread) and
just what will happen if the same iput() is delayed until *after*
evict_inodes(), all the way into ->put_super().  At which point there's
no promise whatsoever that the data structures used by ->evict_inode()
hadn't been already freed...