Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp3387279pxb; Wed, 14 Apr 2021 04:31:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPkMkfNH9c2VdRlZ8Lis77F8v1wbeUyw7mr7KXVIFnqPqaUhuDMlepcemVRgfZ4bAVVm+x X-Received: by 2002:a17:906:5fc2:: with SMTP id k2mr12089303ejv.354.1618399885869; Wed, 14 Apr 2021 04:31:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618399885; cv=none; d=google.com; s=arc-20160816; b=Jo/g0mNHHiFh8GUnJ3U+YYdihovYXG86xSW9Z4NzsVAmTpEc6rirEjJVLUtjAVzQyO orzXYJ+kXK1TTysgBVmuq4Bd+BFpXwULhUO1gHX++v4m1LsBpVRUgNKRHk8d9GmNTrXe dzUFeHBRQ8rC0obNrm79OOHp7GmJFuBDlmJ1hAy2L9OsNzzwPUz3rIETt9Khkf4xtZiv /ZCJtGjRec8CwB+T467nBAHrOYBPK6Lxig9cG5jr6rPNf50Mv6zp4kujLNL5cOW97+tq pgOYjBjaDo/GkRB5d4EGNxGI6rqF96Z+qc0DcbAIZnwUDzLlWDh0WO28d7Pnn/3MaExU NUXQ== 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=0HeuiMXRiEGDvunmaFNMShctHaSrAE7pCA3ZOieDvYo=; b=zJgmNcSS5q+yjvUfmZeQX+kgL7TC6MTenXzxkMOu1YAMykaJ4PXCvRKYXeMY2lApcq QuzCjzD5N1fzgjA2H/3vK3f5rfFIlofHbetVHuevnd/HKOaK3Gvxleo7LGLQw0MTHUBq wzQlbblMlAAg4UWcecXN21A/ICLnuP5C7BEwtH6Vwkp+EHkE645CbUesCHoIixUFOroG 1XdUCHP1kcHDpkm6Gw5GQjZCi96O4HFk+kx4rsMw9BNO4/40zgW2tSrDZczRMWyPrqNV c0SGCnL99/leoiltmdo6rp0JiqB7Mc9HZar8iKiDu9Exkjj5hLYh7SEMCtBx1/6HyXk0 NMog== 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 cm28si12806126edb.397.2021.04.14.04.31.02; Wed, 14 Apr 2021 04:31:25 -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 S236853AbhDNC4W (ORCPT + 99 others); Tue, 13 Apr 2021 22:56:22 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:15675 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233194AbhDNC4R (ORCPT ); Tue, 13 Apr 2021 22:56:17 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FKn8Z4f4bzpXYs; Wed, 14 Apr 2021 10:53:02 +0800 (CST) Received: from [10.174.176.162] (10.174.176.162) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.498.0; Wed, 14 Apr 2021 10:55:52 +0800 Subject: Re: [PATCH 2/5] swap: fix do_swap_page() race with swapoff To: "Huang, Ying" CC: , , , , , , , , , , , , References: <20210408130820.48233-1-linmiaohe@huawei.com> <20210408130820.48233-3-linmiaohe@huawei.com> <87o8ejug76.fsf@yhuang6-desk1.ccr.corp.intel.com> From: Miaohe Lin Message-ID: Date: Wed, 14 Apr 2021 10:55:52 +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: <87o8ejug76.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.176.162] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/4/13 9:27, Huang, Ying wrote: > Miaohe Lin writes: > >> When I was investigating the swap code, I found the below possible race >> window: >> >> CPU 1 CPU 2 >> ----- ----- >> do_swap_page >> synchronous swap_readpage >> alloc_page_vma >> swapoff >> release swap_file, bdev, or ... >> swap_readpage >> check sis->flags is ok >> access swap_file, bdev...[oops!] >> si->flags = 0 >> >> 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 this race may not be really pernicious because swapoff is usually >> done when system shutdown only. 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). >> >> Fixes: 235b62176712 ("mm/swap: add cluster lock") > > This isn't the commit that introduces the race. You can use `git blame` > find out the correct commit. For this it's commit 0bcac06f27d7 "mm, > swap: skip swapcache for swapin of synchronous device". > Sorry about it! What I refer to is commit eb085574a752 ("mm, swap: fix race between swapoff and some swap operations"). And I think this commit does not fix the race condition completely, so I reuse the Fixes tag inside it. > And I suggest to merge 1/5 and 2/5 to make it easy to get the full > picture. > >> Signed-off-by: Miaohe Lin >> --- >> include/linux/swap.h | 2 +- >> mm/memory.c | 10 ++++++++++ >> mm/swapfile.c | 28 +++++++++++----------------- >> 3 files changed, 22 insertions(+), 18 deletions(-) >> >> diff --git a/include/linux/swap.h b/include/linux/swap.h >> index 849ba5265c11..9066addb57fd 100644 >> --- a/include/linux/swap.h >> +++ b/include/linux/swap.h >> @@ -513,7 +513,7 @@ sector_t swap_page_sector(struct page *page); >> >> static inline void put_swap_device(struct swap_info_struct *si) >> { >> - rcu_read_unlock(); >> + percpu_ref_put(&si->users); >> } >> >> #else /* CONFIG_SWAP */ >> diff --git a/mm/memory.c b/mm/memory.c >> index cc71a445c76c..8543c47b955c 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -3311,6 +3311,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) >> { >> struct vm_area_struct *vma = vmf->vma; >> struct page *page = NULL, *swapcache; >> + struct swap_info_struct *si = NULL; >> swp_entry_t entry; >> pte_t pte; >> int locked; >> @@ -3339,6 +3340,11 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) >> } >> >> > > I suggest to add comments here as follows (words copy from Matthew Wilcox) > > /* Prevent swapoff from happening to us */ Ok. > >> + si = get_swap_device(entry); >> + /* In case we raced with swapoff. */ >> + if (unlikely(!si)) >> + goto out; >> + > > Because we wrap the whole do_swap_page() with get/put_swap_device() > now. We can remove several get/put_swap_device() for function called by > do_swap_page(). That can be another optimization patch. I tried to remove several get/put_swap_device() for function called by do_swap_page() only before I send this series. But it seems they have other callers without proper get/put_swap_device(). > >> delayacct_set_flag(DELAYACCT_PF_SWAPIN); >> page = lookup_swap_cache(entry, vma, vmf->address); >> swapcache = page; >> @@ -3514,6 +3520,8 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) >> unlock: >> pte_unmap_unlock(vmf->pte, vmf->ptl); >> out: >> + if (si) >> + put_swap_device(si); >> return ret; >> out_nomap: >> pte_unmap_unlock(vmf->pte, vmf->ptl); >> @@ -3525,6 +3533,8 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) >> unlock_page(swapcache); >> put_page(swapcache); >> } >> + if (si) >> + put_swap_device(si); >> return ret; >> } >> >> diff --git a/mm/swapfile.c b/mm/swapfile.c >> index 724173cd7d0c..01032c72ceae 100644 >> --- a/mm/swapfile.c >> +++ b/mm/swapfile.c >> @@ -1280,18 +1280,12 @@ static unsigned char __swap_entry_free_locked(struct swap_info_struct *p, >> * via preventing the swap device from being swapoff, until >> * put_swap_device() is called. Otherwise return NULL. >> * >> - * The entirety of the RCU read critical section must come before the >> - * return from or after the call to synchronize_rcu() in >> - * enable_swap_info() or swapoff(). So if "si->flags & SWP_VALID" is >> - * true, the si->map, si->cluster_info, etc. must be valid in the >> - * critical section. >> - * >> * Notice that swapoff or swapoff+swapon can still happen before the >> - * rcu_read_lock() in get_swap_device() or after the rcu_read_unlock() >> - * in put_swap_device() if there isn't any other way to prevent >> - * swapoff, such as page lock, page table lock, etc. The caller must >> - * be prepared for that. For example, the following situation is >> - * possible. >> + * percpu_ref_tryget_live() in get_swap_device() or after the >> + * percpu_ref_put() in put_swap_device() if there isn't any other way >> + * to prevent swapoff, such as page lock, page table lock, etc. The >> + * caller must be prepared for that. For example, the following >> + * situation is possible. >> * >> * CPU1 CPU2 >> * do_swap_page() >> @@ -1319,21 +1313,21 @@ struct swap_info_struct *get_swap_device(swp_entry_t entry) >> si = swp_swap_info(entry); >> if (!si) >> goto bad_nofile; >> - >> - rcu_read_lock(); >> if (data_race(!(si->flags & SWP_VALID))) > > We can delete SWP_VALID, that is used together with RCU solution. Will do. > >> - goto unlock_out; >> + goto out; >> + if (!percpu_ref_tryget_live(&si->users)) >> + goto out; >> offset = swp_offset(entry); >> if (offset >= si->max) >> - goto unlock_out; >> + goto put_out; >> >> return si; >> bad_nofile: >> pr_err("%s: %s%08lx\n", __func__, Bad_file, entry.val); >> out: >> return NULL; >> -unlock_out: >> - rcu_read_unlock(); >> +put_out: >> + percpu_ref_put(&si->users); >> return NULL; >> } > Many thanks. > Best Regards, > Huang, Ying > . >