Received: by 2002:a05:7412:40d:b0:e2:908c:2ebd with SMTP id 13csp769230rdf; Tue, 21 Nov 2023 16:42:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IH6VUyNU00Nfb+edAPQjmaELW5o5dBQ2Aj8uE01Vc9rOjc/XKEIK28UJYNZt+97JScrtqU7 X-Received: by 2002:a17:902:f687:b0:1c3:e2eb:f79d with SMTP id l7-20020a170902f68700b001c3e2ebf79dmr6570888plg.8.1700613771958; Tue, 21 Nov 2023 16:42:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700613771; cv=none; d=google.com; s=arc-20160816; b=NLuUNva3YGFDOcaOayADdD88Vg0Ncmp+Vq6iEYlWOmsa76CJVvgTga/nVlx7IdAV2v gdYcZvVIHzdVfyJRQPyrRMPspZfXoyCwgUHmmoqhi9DkNXIhJ6DclXTfPQGQjB6niswb M06c5eKOO/C8089K8wqP6cF2dF2/vsQxGv0EAyaVbsfXWAlmaCJe8BKiXD8UXwYwRXcw 8cHGB9afOVf8jg2MYZ1JvAuBw7qmO6xoMSueArAVWPK1Lsp5r0K+oulWae07ISkDF2dx Z1FghPETHQfJZKCDey8ioHL2TYTIbwVwfJHucdWvQBl7quOv9fbpSNQ1atoetGnhCnq8 7fEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:dkim-signature; bh=SuFOQjF2EkL2m8qxQ/qOi5j7x7wUqgxHevGV9ga6ufI=; fh=zMupsO78S1yMDhYJ34WriRUZV9bXCCZeIDeHMXk4My8=; b=UoCMZflhBbdbgx7pKGc5zMxk/PBxG9MEbiRp8B+yYGQBZWomCCpuXXFnJjQJR+Ckxu p21eevOcv12wj0lMXcNNVUQXZVI88eWsDoK+qS2J/2btW3pdecp9O0kNdBkUFWN7R8q2 9NBBOsI92NcBX0IGxgaa8X5Sjlre+GMwAeFu3BmNzOKEsbdXcntrDVNrEMrjfhGREKjo AC1XNSfxjGuLIDSnOBZ5Xb5L0wG0qIKxfEtPf2AKZOO2mbAmCgkN4M/vCXXRU3Wyyzi6 ujPddtOrOS4SAynPauPuZv/Dk9RNB4e6V3Zvq+FuZGH+pITITDGVmknyJuzW7k4ieKBH UdzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TvkH584s; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id u24-20020a63df18000000b005b8fb1da631si11953685pgg.897.2023.11.21.16.42.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Nov 2023 16:42:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TvkH584s; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id CF48A8183EE6; Tue, 21 Nov 2023 16:42:49 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234703AbjKVAiy (ORCPT + 99 others); Tue, 21 Nov 2023 19:38:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38182 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229527AbjKVAix (ORCPT ); Tue, 21 Nov 2023 19:38:53 -0500 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28FD8D56 for ; Tue, 21 Nov 2023 16:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1700613520; x=1732149520; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=O4nuBJ8lPxlgr4H6Unme6GXB+1ph0KAzNAaPeOJjdRo=; b=TvkH584s/iwJPSvsz+e2lkL+po+C6oOq1cBA91i3A6lPsh6oGd3WBmPJ eODDQjXeOnKaKZjh6S88ha51k1YNk3Z1GyhSQfl/moogc934AoN94UJyD mz4tq9hxfi3rZZ60fxihde+CbiR9jWweLJpV0HdCPCu/UHa7ScwqCARe0 FulgRD1GExf9CTZYKnyBvk9A5B6IDynhPUXl/iSDwgHN8umgF8f4UUKbP DumEhumBJMbVc9zYb4a7mI++4wRJKgPjGMrZuKC81e49fgkzAU6AzNKZ0 +C44s6luIfGObXjM1RLyOlvFjqDo+CPW+O6qnIku2/fKWUeg1bIsBhTW0 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10901"; a="372125901" X-IronPort-AV: E=Sophos;i="6.04,217,1695711600"; d="scan'208";a="372125901" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Nov 2023 16:38:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.04,217,1695711600"; d="scan'208";a="8264591" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Nov 2023 16:38:37 -0800 From: "Huang, Ying" To: Kairui Song Cc: linux-mm@kvack.org, Kairui Song , Andrew Morton , David Hildenbrand , Hugh Dickins , Johannes Weiner , Matthew Wilcox , Michal Hocko , linux-kernel@vger.kernel.org Subject: Re: [PATCH 16/24] mm/swap: reduce scope of get_swap_device in swapin path In-Reply-To: <20231119194740.94101-17-ryncsn@gmail.com> (Kairui Song's message of "Mon, 20 Nov 2023 03:47:32 +0800") References: <20231119194740.94101-1-ryncsn@gmail.com> <20231119194740.94101-17-ryncsn@gmail.com> Date: Wed, 22 Nov 2023 08:36:36 +0800 Message-ID: <87sf4yaajv.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 21 Nov 2023 16:42:50 -0800 (PST) Kairui Song writes: > From: Kairui Song > > Move get_swap_device into swapin_readahead, simplify the code > and prepare for follow up commits. No. Please don't do this. Please check the get/put_swap_device() usage rule in the comments of get_swap_device(). " * When we get a swap entry, if there aren't some other ways to * prevent swapoff, such as the folio in swap cache is locked, page * table lock is held, etc., the swap entry may become invalid because * of swapoff. Then, we need to enclose all swap related functions * with get_swap_device() and put_swap_device(), unless the swap * functions call get/put_swap_device() by themselves. " This is to simplify the reasoning about swapoff and swap entry. Why does it bother you? > For the later part in do_swap_page, using swp_swap_info directly is fine > since in that context, the swap device is pinned by swapcache reference. [snip] -- Best Regards, Huang, Ying