From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17F52C433DB for ; Tue, 30 Mar 2021 01:58:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A18146198F for ; Tue, 30 Mar 2021 01:58:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A18146198F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DD9FF6B007E; Mon, 29 Mar 2021 21:58:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB0546B0080; Mon, 29 Mar 2021 21:58:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C78356B0081; Mon, 29 Mar 2021 21:58:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0122.hostedemail.com [216.40.44.122]) by kanga.kvack.org (Postfix) with ESMTP id ABD246B007E for ; Mon, 29 Mar 2021 21:58:05 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6F98F180AD80F for ; Tue, 30 Mar 2021 01:58:05 +0000 (UTC) X-FDA: 77974880130.34.745C041 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf19.hostedemail.com (Postfix) with ESMTP id 6667F90009E2 for ; Tue, 30 Mar 2021 01:57:56 +0000 (UTC) IronPort-SDR: c8XtwTNThqEQg1T0At3sx9tHOZnqUb0a/ko5UZQyWlKo4DbrRXUwDCT9JcphMENxY9420ZJE9h ugXLBYVareog== X-IronPort-AV: E=McAfee;i="6000,8403,9938"; a="189416368" X-IronPort-AV: E=Sophos;i="5.81,289,1610438400"; d="scan'208";a="189416368" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2021 18:58:01 -0700 IronPort-SDR: oZrfYiEFLYHlv33w1/1ygwjh5hfSEQi2PdpgjdsJ55B6ynmAGxF5Xsq+49kCowZkCbOsI1+dWM sAPTeRzemSmg== X-IronPort-AV: E=Sophos;i="5.81,289,1610438400"; d="scan'208";a="417938943" Received: from yhuang6-desk1.sh.intel.com (HELO yhuang6-desk1.ccr.corp.intel.com) ([10.239.13.1]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2021 18:57:58 -0700 From: "Huang, Ying" To: Miaohe Lin Cc: Linux-MM , linux-kernel , Andrew Morton , Matthew Wilcox , Yu Zhao , Shakeel Butt , Alex Shi , Minchan Kim Subject: Re: [Question] Is there a race window between swapoff vs synchronous swap_readpage References: <364d7ce9-ccb7-fa04-7067-44a96be87060@huawei.com> Date: Tue, 30 Mar 2021 09:57:55 +0800 In-Reply-To: <364d7ce9-ccb7-fa04-7067-44a96be87060@huawei.com> (Miaohe Lin's message of "Mon, 29 Mar 2021 21:18:20 +0800") Message-ID: <8735wdbdy4.fsf@yhuang6-desk1.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Stat-Signature: 3egsjf53bnp4hbtmmsz79w3b1epubn6t X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6667F90009E2 Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf19; identity=mailfrom; envelope-from=""; helo=mga04.intel.com; client-ip=192.55.52.120 X-HE-DKIM-Result: none/none X-HE-Tag: 1617069476-930390 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, Miaohe, Miaohe Lin writes: > Hi all, > I am investigating the swap code, and I found the below possible race window: > > CPU 1 CPU 2 > ----- ----- > do_swap_page > skip swapcache case (synchronous swap_readpage) > alloc_page_vma > swapoff > release swap_file, bdev, or ... > swap_readpage > check sis->flags is ok > access swap_file, bdev or ...[oops!] > si->flags = 0 > > The swapcache case is ok because swapoff will wait on the page_lock of swapcache page. > Is this will really happen or Am I miss something ? > Any reply would be really grateful. Thanks! :) This appears possible. Even for swapcache case, we can't guarantee the swap entry gotten from the page table is always valid too. The underlying swap device can be swapped off at the same time. So we use get/put_swap_device() for that. Maybe we need similar stuff here. Best Regards, Huang, Ying