Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1153065pxf; Fri, 9 Apr 2021 01:03:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7XPv1IJ04IlVc0Pas2zKIOQQxjTtAPhUKjl4tYxUKQK3+/KELVeu4XhZZtjs/qcvdvbwx X-Received: by 2002:a17:906:f283:: with SMTP id gu3mr14774516ejb.91.1617955391300; Fri, 09 Apr 2021 01:03:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617955391; cv=none; d=google.com; s=arc-20160816; b=CekPmkuglmhpVO4TPa1cx7tT2f9aD0mJnFAdSunGnmxnT9ThgwPv3DsKUyJ4lBBbB6 l2wy4t0EnJ291UfO7fVTZkKNanRBqMQtr+BDrkv3zvMYfF2HCYhuyhUzaodx2iq4XPpc Z25QVQ/eWuaB6S3PPaB9HmeOH5Y7lDGNsx6ZVbhzd6nrLwif1Gls9mpgB7Yr1PFQq/YA aKObzqoQkx4X38II7hKB78MwixAB0ZxDhP783qArSW6tybka1vE1Mf7O68GF+kSCUpAR Fl7IWKP0dOF7AXCVaMOFXCXk9q2UbU7N06naCBTXenOzIlO5sKcNR+4VPBPk1v2MdsnB a28w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=EB+IjjCM6ceXmlepzk8Dzx/oewLPnivvOxCTo28oPqM=; b=c+Dsn0CH9M5ekzXtbYYIKlA3B9fPK+Lc7NW9K47jqCc3qwEneAqOQnDYFokgmfvF1G ghg59otpWJy9nY9DNiOO9sDrUB/eTdm5fffn1G0POyWDj3RJOxUy1s+d2/AtmUItWWVo t2uEHvptCInExcoKOogAU/FiqEmVVQtm3tfxutM17GSxPRDG4VzRAkNx37DNQG1qgyxO vDW30KBCrVKN4zLEXuTlcpgA0Wq/qJkVh+p2caLJ1k4+zxitLvGyIbM9//8JLtFQnIDc MORG4Fdr1ZijGBH6PrYymhZ28sORexfewarbV9cjbnDITHrahWUKY6yRbt8bxl4zBpfm qeCQ== 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 m7si1764230edq.562.2021.04.09.01.02.48; Fri, 09 Apr 2021 01:03:11 -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 S232267AbhDIIBo (ORCPT + 99 others); Fri, 9 Apr 2021 04:01:44 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:16110 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231496AbhDIIBn (ORCPT ); Fri, 9 Apr 2021 04:01:43 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FGrBD65z7z1BGK1; Fri, 9 Apr 2021 15:59:16 +0800 (CST) Received: from [10.174.179.9] (10.174.179.9) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.498.0; Fri, 9 Apr 2021 16:01:23 +0800 Subject: Re: [PATCH 0/5] close various race windows for swap To: riteshh CC: , , , , , , , , , , , , , References: <20210408130820.48233-1-linmiaohe@huawei.com> <20210408145517.jqodfz6cmm4wwk7g@riteshh-domain> From: Miaohe Lin Message-ID: <48892512-c2f7-9898-0373-a185975b456c@huawei.com> Date: Fri, 9 Apr 2021 16:01:23 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210408145517.jqodfz6cmm4wwk7g@riteshh-domain> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.9] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/4/8 22:55, riteshh wrote: > On 21/04/08 09:08AM, Miaohe Lin wrote: >> Hi all, >> When I was investigating the swap code, I found some possible race >> windows. This series aims to fix all these races. But using current >> get/put_swap_device() to guard against concurrent swapoff for >> swap_readpage() looks terrible because swap_readpage() may take really >> long time. And to reduce the performance overhead on the hot-path as >> much as possible, it appears we can use the percpu_ref to close this >> race window(as suggested by Huang, Ying). The patch 1 adds percpu_ref >> support for swap and the rest of the patches use this to close various >> race windows. More details can be found in the respective changelogs. >> Thanks! >> >> Miaohe Lin (5): >> mm/swapfile: add percpu_ref support for swap >> swap: fix do_swap_page() race with swapoff >> mm/swap_state: fix get_shadow_from_swap_cache() race with swapoff >> mm/swap_state: fix potential faulted in race in swap_ra_info() >> mm/swap_state: fix swap_cluster_readahead() race with swapoff > Many thanks for quick respond. > Somehow I see Patch-1 and Patch-2 are missing on linux-mm[1]. I have no idea why Patch-1 and Patch-2 are missing. But they could be found at: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2542188.html > Also I wanted to ask if you have a way to trigger this in a more controlled > environment (consistently)? > This is *theoretical* issue. The race window is very small but not impossible. Please see the discussion: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2530094.html > [1]: https://patchwork.kernel.org/project/linux-mm/cover/20210408130820.48233-1-linmiaohe@huawei.com/ > Thanks again. > -ritesh > >> >> include/linux/swap.h | 4 +++- >> mm/memory.c | 10 +++++++++ >> mm/swap_state.c | 33 +++++++++++++++++++++-------- >> mm/swapfile.c | 50 +++++++++++++++++++++++++++----------------- >> 4 files changed, 68 insertions(+), 29 deletions(-) >> >> -- >> 2.19.1 >> >> > . >