Received: by 10.223.185.116 with SMTP id b49csp2392504wrg; Mon, 5 Mar 2018 01:59:01 -0800 (PST) X-Google-Smtp-Source: AG47ELuZ42Sy33fj+pLWga6vU7TxLGKvklPguY4wqEGIU6ggPPuLFEQREUsweEGkxSPHMvl80+lY X-Received: by 2002:a17:902:76cb:: with SMTP id j11-v6mr12688334plt.431.1520243941121; Mon, 05 Mar 2018 01:59:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520243941; cv=none; d=google.com; s=arc-20160816; b=Lt+pu1xFpUSeJUNQ12wea52vuf7yUaCgXOmJadBwXGB2waz7vB0C+P20bscBtPE4My /OJLze6BpN/hog/mrCMB3mFdhRTIjvTJ2g7pFNB709MGrxDYL2T6pHLjIhXinvU/ofaB 6JVJ7sTmaY+RKJkgOguz5FMbT4j6s2RvIgrp8hidx3kBeV2Z/VKQoKsJdMVnpm/J7fNr di8O9noUDffwYbuhS6GgKNm0ZkGnB/hpOTO+7jxRMU78PmPXTr2tjHynySPPIsgXjVgo YrL1Gl4UeV5G0Dy63aAjDzh/FjspVGwUAI2AAA/mC1x+7QKaeIucQQFDzdsJtN9OH8Yg hJzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:user-agent:in-reply-to :content-disposition:mime-version:references:subject:cc:to:from:date :arc-authentication-results; bh=mAXxRY1+NYfFndn/cM2Ue0SK0JqGVBXzBfuMXUbnYqc=; b=c7cqVw0IR+K7GI1NpBK1+aEB43s2NB8CVfYP4dva4KJfmKrInAWT9/IhhEew7rkAM9 HbhKPQETvhzIUaXWAejDCw1RPUD43jkiVKHWcqrbku8bdhRDaLtE6hjBFDAKiKfA/4M6 dzpZQ94FfACf30tDsWO+kxU6O11JuWPbMvXlmP0NQgZCE4pBc2a+6a18QiQ0ggd0uyUf 9CNNFjtURHC2ezuM42iCi74iiY+UZC6zjTeaNC0T6yexo/gZ/InOs0OgQ5tg9huHRZI2 OFIJPRuX2cjSsGlur668t351T/PS6HbHMErVdv05SjL/+sr6DRb3/ikv2DdC/4uLmyTl ORoQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k20-v6si9082360pls.294.2018.03.05.01.58.46; Mon, 05 Mar 2018 01:59:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933831AbeCEJqZ (ORCPT + 99 others); Mon, 5 Mar 2018 04:46:25 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:43760 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933048AbeCEJqX (ORCPT ); Mon, 5 Mar 2018 04:46:23 -0500 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w259iO6O003049 for ; Mon, 5 Mar 2018 04:46:23 -0500 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 2gh2uu9xay-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Mon, 05 Mar 2018 04:46:21 -0500 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 5 Mar 2018 09:46:18 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 5 Mar 2018 09:46:11 -0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w259kB6H10223758; Mon, 5 Mar 2018 09:46:11 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DB80C5203F; Mon, 5 Mar 2018 08:37:50 +0000 (GMT) Received: from rapoport-lnx (unknown [9.148.206.64]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTPS id E8B4F52043; Mon, 5 Mar 2018 08:37:45 +0000 (GMT) Date: Mon, 5 Mar 2018 10:46:02 +0100 From: Mike Rapoport To: "Huang, Ying" Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , Michal Hocko , Johannes Weiner , Mel Gorman , Dave Hansen , Chen Liqin , Russell King , Yoshinori Sato , "James E.J. Bottomley" , Guan Xuetao , "David S. Miller" , Chris Zankel , Vineet Gupta , Ley Foon Tan , Ralf Baechle , Andi Kleen Subject: Re: [PATCH -V2 -mm] mm: Fix races between swapoff and flush dcache References: <20180305083634.15174-1-ying.huang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180305083634.15174-1-ying.huang@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-GCONF: 00 x-cbid: 18030509-0040-0000-0000-0000041AD534 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18030509-0041-0000-0000-0000261DE349 Message-Id: <20180305094601.GA25231@rapoport-lnx> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-05_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=18 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1803050116 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 05, 2018 at 04:36:34PM +0800, Huang, Ying wrote: > From: Huang Ying > > From commit 4b3ef9daa4fc ("mm/swap: split swap cache into 64MB > trunks") on, after swapoff, the address_space associated with the swap > device will be freed. So page_mapping() users which may touch the > address_space need some kind of mechanism to prevent the address_space > from being freed during accessing. > > The dcache flushing functions (flush_dcache_page(), etc) in > architecture specific code may access the address_space of swap device > for anonymous pages in swap cache via page_mapping() function. But in > some cases there are no mechanisms to prevent the swap device from > being swapoff, for example, > > CPU1 CPU2 > __get_user_pages() swapoff() > flush_dcache_page() > mapping = page_mapping() > ... exit_swap_address_space() > ... kvfree(spaces) > mapping_mapped(mapping) > > The address space may be accessed after being freed. > > But from cachetlb.txt and Russell King, flush_dcache_page() only care > about file cache pages, for anonymous pages, flush_anon_page() should > be used. The implementation of flush_dcache_page() in all > architectures follows this too. They will check whether > page_mapping() is NULL and whether mapping_mapped() is true to > determine whether to flush the dcache immediately. And they will use > interval tree (mapping->i_mmap) to find all user space mappings. > While mapping_mapped() and mapping->i_mmap isn't used by anonymous > pages in swap cache at all. > > So, to fix the race between swapoff and flush dcache, __page_mapping() > is add to return the address_space for file cache pages and NULL > otherwise. All page_mapping() invoking in flush dcache functions are > replaced with __page_mapping(). > > Signed-off-by: "Huang, Ying" > Cc: Minchan Kim > Cc: Michal Hocko > Cc: Johannes Weiner > Cc: Mel Gorman > Cc: Dave Hansen > Cc: Chen Liqin > Cc: Russell King > Cc: Yoshinori Sato > Cc: "James E.J. Bottomley" > Cc: Guan Xuetao > Cc: "David S. Miller" > Cc: Chris Zankel > Cc: Vineet Gupta > Cc: Ley Foon Tan > Cc: Ralf Baechle > Cc: Andi Kleen > > Changes: > > v2: > > - Rename __page_mapping() to page_mapping_file() and simplified > implementation as suggested by Andrew Morton. > --- > arch/arc/mm/cache.c | 2 +- > arch/arm/mm/copypage-v4mc.c | 2 +- > arch/arm/mm/copypage-v6.c | 2 +- > arch/arm/mm/copypage-xscale.c | 2 +- > arch/arm/mm/fault-armv.c | 2 +- > arch/arm/mm/flush.c | 6 +++--- > arch/mips/mm/cache.c | 2 +- > arch/nios2/mm/cacheflush.c | 4 ++-- > arch/parisc/kernel/cache.c | 5 +++-- > arch/score/mm/cache.c | 5 +++-- > arch/sh/mm/cache-sh4.c | 2 +- > arch/sh/mm/cache-sh7705.c | 2 +- > arch/sparc/kernel/smp_64.c | 8 ++++---- > arch/sparc/mm/init_64.c | 6 +++--- > arch/sparc/mm/tlb.c | 2 +- > arch/unicore32/mm/flush.c | 2 +- > arch/unicore32/mm/mmu.c | 2 +- > arch/xtensa/mm/cache.c | 2 +- > include/linux/mm.h | 1 + > mm/util.c | 11 +++++++++++ > 20 files changed, 42 insertions(+), 28 deletions(-) ... > diff --git a/mm/util.c b/mm/util.c > index d800ce40816c..252f4748f00b 100644 > --- a/mm/util.c > +++ b/mm/util.c > @@ -515,6 +515,17 @@ struct address_space *page_mapping(struct page *page) > } > EXPORT_SYMBOL(page_mapping); > > +/* > + * For file cache pages, return the address_space, otherwise return NULL > + */ > +struct address_space *page_mapping_file(struct page *page) > +{ > + if (unlikely(PageSwapCache(page))) > + return NULL; > + else Nit: you can drop the 'else' and just fall through to return page_mapping(page). > + return page_mapping(page); > +} > + > /* Slow path of page_mapcount() for compound pages */ > int __page_mapcount(struct page *page) > { > -- > 2.15.1 > -- Sincerely yours, Mike.