Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2225943pxb; Sun, 18 Apr 2021 23:51:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwXmFQS5bLzhw7EE5vI0gt4l1FDRlPp6BLYBydi16O7DzQYRbOcZfwl9aPFBq2NYHzyAZ+q X-Received: by 2002:a17:906:341a:: with SMTP id c26mr20157150ejb.238.1618815118398; Sun, 18 Apr 2021 23:51:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618815118; cv=none; d=google.com; s=arc-20160816; b=Hlo5oMYGg980zS5Av5ZmOoRCBZUh+GU9icQDF3M7ydUVI6YG7Y7DErqHA+mwlnZp6h BNIKwulRosfns57usolqRDFt/kvjGn5CR93BmGVSBocpoqSZMU6xSkFYr9w+8i8LHpYP YQOH6TNuqkSdweLu1DzpWGKprhnyOMdzBfrK1y3BOOi2ELwUBXmW3NuzJITO1xXm/LfL HoinL1NpwykPWmfbPlkGsUnvqE4Uw3TAdfxaC8wrSwc2sBQc+RsEqQYiSTEInMKmV9Mb BYfGBKr611XvkYxL+/htqSkNSQISqsjUWuSqtZgPsnUtDICnMn5ym/zRHXCmPNUo5Htp plAQ== 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=648SAbt867cLJXBOz2nHRWIVAQsjJHlwfwH54Pp6b50=; b=zMheTcfYYPwpYmuGx3STBg0/BiGVLiv0O84thNFJnbo1KqZVZR3ozgPPTk8pY63yNb XtL3nkAgOOe43q01cN5xT3uYt/8Y3xjyoTnhbVG5sbBhi7EvKzqLs46w7RvPMHSvk3gQ AR0/8uMEqmg14Cqc3mDLkFVG9joCxn8Ng+FmKNei5FVX3zQGTmH9VUXHYAAC41OsGbIc bppOKn0rWe2D1spYmQ9r/C0KfI+4Qxk2BBzwEYQZxCzvDt01QeXvH3qq5FTZZ+snvoBI 1MH5Vucb9qy5WzTjJ1aT2sbS03xqv8qyBviYh0C9Nc3+A0pkjxIBkD3RDTfL3hvd7r2R 4eYQ== 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 25si10921854ejy.309.2021.04.18.23.51.35; Sun, 18 Apr 2021 23:51:58 -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 S229671AbhDSGut (ORCPT + 99 others); Mon, 19 Apr 2021 02:50:49 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:16599 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231556AbhDSGur (ORCPT ); Mon, 19 Apr 2021 02:50:47 -0400 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FNy6q6WWqz16LBl; Mon, 19 Apr 2021 14:47:31 +0800 (CST) Received: from [10.174.178.5] (10.174.178.5) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.498.0; Mon, 19 Apr 2021 14:49:48 +0800 Subject: Re: [PATCH v2 5/5] mm/shmem: fix shmem_swapin() race with swapoff To: "Huang, Ying" CC: , , , , , , , , , , , , References: <20210417094039.51711-1-linmiaohe@huawei.com> <20210417094039.51711-6-linmiaohe@huawei.com> <87r1j7kok3.fsf@yhuang6-desk1.ccr.corp.intel.com> From: Miaohe Lin Message-ID: Date: Mon, 19 Apr 2021 14:49:47 +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: <87r1j7kok3.fsf@yhuang6-desk1.ccr.corp.intel.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.5] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/4/19 10:15, Huang, Ying wrote: > Miaohe Lin writes: > >> When I was investigating the swap code, I found the below possible race >> window: >> >> CPU 1 CPU 2 >> ----- ----- >> shmem_swapin >> swap_cluster_readahead >> if (likely(si->flags & (SWP_BLKDEV | SWP_FS_OPS))) { >> swapoff >> si->flags &= ~SWP_VALID; >> .. >> synchronize_rcu(); >> .. > > You have removed these code in the previous patches of the series. And > they are not relevant in this patch. Yes, I should change these. Thanks. > >> si->swap_file = NULL; >> struct inode *inode = si->swap_file->f_mapping->host;[oops!] >> >> Close this race window by using get/put_swap_device() to guard against >> concurrent swapoff. >> >> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > > No. This isn't the commit that introduces the race condition. Please > recheck your git blame result. > I think this is really hard to find exact commit. I used git blame and found this race should be existed when this is introduced. Any suggestion ? Thanks. > Best Regards, > Huang, Ying > >> Signed-off-by: Miaohe Lin >> --- >> mm/shmem.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/mm/shmem.c b/mm/shmem.c >> index 26c76b13ad23..936ba5595297 100644 >> --- a/mm/shmem.c >> +++ b/mm/shmem.c >> @@ -1492,15 +1492,21 @@ static void shmem_pseudo_vma_destroy(struct vm_area_struct *vma) >> static struct page *shmem_swapin(swp_entry_t swap, gfp_t gfp, >> struct shmem_inode_info *info, pgoff_t index) >> { >> + struct swap_info_struct *si; >> struct vm_area_struct pvma; >> struct page *page; >> struct vm_fault vmf = { >> .vma = &pvma, >> }; >> >> + /* Prevent swapoff from happening to us. */ >> + si = get_swap_device(swap); >> + if (unlikely(!si)) >> + return NULL; >> shmem_pseudo_vma_init(&pvma, info, index); >> page = swap_cluster_readahead(swap, gfp, &vmf); >> shmem_pseudo_vma_destroy(&pvma); >> + put_swap_device(si); >> >> return page; >> } > . >