From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751926AbeABKVK (ORCPT + 1 other); Tue, 2 Jan 2018 05:21:10 -0500 Received: from mx2.suse.de ([195.135.220.15]:37247 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751687AbeABKVI (ORCPT ); Tue, 2 Jan 2018 05:21:08 -0500 Date: Tue, 2 Jan 2018 10:21:03 +0000 From: Mel Gorman To: Minchan Kim Cc: "Huang, Ying" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Hugh Dickins , "Paul E . McKenney" , Johannes Weiner , Tim Chen , Shaohua Li , Mel Gorman , J???r???me Glisse , Michal Hocko , Andrea Arcangeli , David Rientjes , Rik van Riel , Jan Kara , Dave Jiang , Aaron Lu Subject: Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations Message-ID: <20180102102103.mpah2ehglufwhzle@suse.de> References: <20171220012632.26840-1-ying.huang@intel.com> <20171221021619.GA27475@bbox> <871sjopllj.fsf@yhuang-dev.intel.com> <20171221235813.GA29033@bbox> <87r2rmj1d8.fsf@yhuang-dev.intel.com> <20171223013653.GB5279@bgram> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20171223013653.GB5279@bgram> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Sat, Dec 23, 2017 at 10:36:53AM +0900, Minchan Kim wrote: > > code path. It appears that similar situation is possible for them too. > > > > The file cache pages will be delete from file cache address_space before > > address_space (embedded in inode) is freed. But they will be deleted > > from LRU list only when its refcount dropped to zero, please take a look > > at put_page() and release_pages(). While address_space will be freed > > after putting reference to all file cache pages. If someone holds a > > reference to a file cache page for quite long time, it is possible for a > > file cache page to be in LRU list after the inode/address_space is > > freed. > > > > And I found inode/address_space is freed witch call_rcu(). I don't know > > whether this is related to page_mapping(). > > > > This is just my understanding. > > Hmm, it smells like a bug of __isolate_lru_page. > > Ccing Mel: > > What locks protects address_space destroying when race happens between > inode trauncation and __isolate_lru_page? > I'm just back online and have a lot of catching up to do so this is a rushed answer and I didn't read the background of this. However the question is somewhat ambiguous and the scope is broad as I'm not sure which race you refer to. For file cache pages, I wouldnt' expect the address_space to be destroyed specifically as long as the inode exists which is the structure containing the address_space in this case. A page on the LRU being isolated in __isolate_lru_page will have an elevated reference count which will pin the inode until remove_mapping is called which holds the page lock while inode truncation looking at a page for truncation also only checks page_mapping under the page lock. Very broadly speaking, pages avoid being added back to an inode being freed by checking the I_FREEING state. Hopefully that helps while I go back to the TODO mountain. -- Mel Gorman SUSE Labs