Messages in this thread | | | Date | Tue, 2 Jan 2018 10:21:03 +0000 | From | Mel Gorman <> | Subject | Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations |
| |
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
| |