Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp3595594pxy; Mon, 26 Apr 2021 05:35:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyMfoL78tijxlxBgF2pYGQK037K9/RS5Cj+fyBE08Hc4F52ixnQfni3cPzdmMxEJ9LY6Aph X-Received: by 2002:a17:903:18e:b029:ec:b394:981f with SMTP id z14-20020a170903018eb02900ecb394981fmr18565660plg.6.1619440518783; Mon, 26 Apr 2021 05:35:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619440518; cv=none; d=google.com; s=arc-20160816; b=ECGD+rlv+8QpvbtEFlr/w6HLPra40NfwJobSCxKDLinOD4rZeMgdBCCOlX034cF4n6 6Jnk7mKjZaIataTrcxTBX1HHIPZ5mv8p5npUgjhjGC+0Afnm8xasgfQcFmRlH1LMbC72 6o6DbbfsWLqdvJ+tlue4jp/D3dotyx1/oSbH3t5L9T/Nn0i72rwN9IOxScUdO/ehTOd2 l419Ahznr5Of+rmWCMgyiY/3um+znCkzZ4/Sj6frMar7A8NMGF2/XFkp6Y1k67kiJdGJ EUlp5IEweyPw+s6DpV6yBIhLgt9mebbH0i4mGLAuiBCQ5RYytOM1HS6XZ96CJTYs4kgl yywQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=rEcrSdsQsTUIRwyCQi5nNEy+Kx0s3X8/6cplsz3jRfs=; b=k84PEY9lzSFA5ys+YFJJvfSb3ziFkU+1NyHXcwoBxLXf4+5fqHOtm7xf0vXQdsUZVZ zMxpF0j38oVNf5HgufviL2Qxu6YeFgJE5ILAubcQ/mdDpX+lE4ennO9zjIqGLlN2CuAd tlrsPAFpoNNff4kA+6ca0rP4UEEOVhMZo1zD84aFuyYdBbkMmWa1EgUSb/BiI7aGc8he SkzYB61xEzoGnl75MzqhtWdm5vgHT5ZFVM11uDvlDuZmMBLb3qGZqLLg4Upbs1a/z3VS aQnIKgflW0LQ5kjHRvH+iLcAOBpkHkQfGPb0TMzXpX5TU/hxa5E79LwvodfNwtjxVr5z W7kQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w10si16930312pgf.338.2021.04.26.05.35.06; Mon, 26 Apr 2021 05:35:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233449AbhDZMeh (ORCPT + 99 others); Mon, 26 Apr 2021 08:34:37 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:17060 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233428AbhDZMef (ORCPT ); Mon, 26 Apr 2021 08:34:35 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FTPQQ33KRz19M37; Mon, 26 Apr 2021 20:31:26 +0800 (CST) Received: from huawei.com (10.175.104.170) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.498.0; Mon, 26 Apr 2021 20:33:43 +0800 From: Miaohe Lin To: CC: , , , , , , , , , , , , , , , , Subject: [PATCH v6 3/4] mm/swap: remove confusing checking for non_swap_entry() in swap_ra_info() Date: Mon, 26 Apr 2021 20:33:15 +0800 Message-ID: <20210426123316.806267-4-linmiaohe@huawei.com> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20210426123316.806267-1-linmiaohe@huawei.com> References: <20210426123316.806267-1-linmiaohe@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.104.170] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The non_swap_entry() was used for working with VMA based swap readahead via commit ec560175c0b6 ("mm, swap: VMA based swap readahead"). At that time, the non_swap_entry() checking is necessary because the function is called before checking that in do_swap_page(). Then it's moved to swap_ra_info() since commit eaf649ebc3ac ("mm: swap: clean up swap readahead"). After that, the non_swap_entry() checking is unnecessary, because swap_ra_info() is called after non_swap_entry() has been checked already. The resulting code is confusing as the non_swap_entry() check looks racy now because while we released the pte lock, somebody else might have faulted in this pte. So we should check whether it's swap pte first to guard against such race or swap_type will be unexpected. But the race isn't important because it will not cause problem. We would have enough checking when we really operate the PTE entries later. So we remove the non_swap_entry() check here to avoid confusion. Reviewed-by: "Huang, Ying" Signed-off-by: Miaohe Lin --- mm/swap_state.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/mm/swap_state.c b/mm/swap_state.c index 272ea2108c9d..df5405384520 100644 --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -721,7 +721,6 @@ static void swap_ra_info(struct vm_fault *vmf, { struct vm_area_struct *vma = vmf->vma; unsigned long ra_val; - swp_entry_t entry; unsigned long faddr, pfn, fpfn; unsigned long start, end; pte_t *pte, *orig_pte; @@ -739,11 +738,6 @@ static void swap_ra_info(struct vm_fault *vmf, faddr = vmf->address; orig_pte = pte = pte_offset_map(vmf->pmd, faddr); - entry = pte_to_swp_entry(*pte); - if ((unlikely(non_swap_entry(entry)))) { - pte_unmap(orig_pte); - return; - } fpfn = PFN_DOWN(faddr); ra_val = GET_SWAP_RA_VAL(vma); -- 2.23.0