Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1170933pxa; Thu, 20 Aug 2020 04:40:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxglBApZTKJKA6/2z5rfgpVbFXroG0ULKHd6VybtCG4sPjWqVK1yAzdHuuiFoXz++1AD6Fe X-Received: by 2002:a05:6402:b45:: with SMTP id bx5mr2523920edb.22.1597923626319; Thu, 20 Aug 2020 04:40:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597923626; cv=none; d=google.com; s=arc-20160816; b=LpptkrCbleukypLe7CgZZJHvVyvs2Fs0A5IFtEduWEKBUCXAqehEf1NdeXg5b6zlYC 5snfjxjG37yI+mJrmcw6urTS40hnQpPzpVnohvW6rfSE0siqtJDR/eoSzHfwNn/KYlmR UFyRkfqWMqX56AXeRdTY8cWN7owGWI8i8p7W4DctkCvAJhYJNIG6RPVlRdpc41ftHGrg UAbSoSJ/HZkP395W67X2/gargz7pysJ2KAHDFLjyS6bNbysX58fdhK42hjSvpXM1xWYm wdwoBo77AhqyaKCKHrGY/XG85SZElNrlY8w+/AWCuGhERVLVBQbUma7EaNd+xzAjb+as 0IXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=t84+Z949JCHOIrLVWyab10y1aUar8zezYlYXe5c2wbk=; b=JplsVfM5MnF5ZwkPeziZx5J2/CF4dgpquvlvzQcbTxtxnGBGTKvvdB28aBl5BqBbcE UlovXihBMuzsFmF+dyGa8c6DyVZ0kiIufRJ8bHYQRRnlORhcbVevfASCTlXA7lX7s2Kw JYPA4B3pbNqi03u0h2mx+MXP8R9mnotQvz4CuDcSlqDcReSWzDE53vjzJKOLzjmxHZkp 2Wt2Z01lwLYI0wHQqMm/bySUZYAb+ay220+Q/XscvDtMiosI1A3evV5H+FePEmwlX1ii 4itKDsH+ILUxOcAWm80kHmdWebKNFT6MGC5Drvgmpg7BMWSJK0IQKT2Cynj/mG079iHu T8yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=casper.20170209 header.b=Vah+zRC1; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k26si1032522ejz.115.2020.08.20.04.40.02; Thu, 20 Aug 2020 04:40:26 -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; dkim=fail header.i=@infradead.org header.s=casper.20170209 header.b=Vah+zRC1; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730757AbgHTLh5 (ORCPT + 99 others); Thu, 20 Aug 2020 07:37:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730849AbgHTLfD (ORCPT ); Thu, 20 Aug 2020 07:35:03 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98E88C061385; Thu, 20 Aug 2020 04:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=t84+Z949JCHOIrLVWyab10y1aUar8zezYlYXe5c2wbk=; b=Vah+zRC10NBMvc8xBtg+tjZiTo FG7tUUZHI4+gor8Ux3uZza/5rQmRIf34CLhjWtUc4glJBovY5Zt8tMIGwnOKg026bwsrH9lojI7bL E2pXK2kM1ZFDkhxnJx44Kyexr0FfrbS+K7Ic7AF3qsysKTCBWa9tiIRJMbzNOvApL0RROg2bxNoiN 6l383zlJUyuwUumLjB0w/Xi3RreLD+9ipEDkwtIPtksBVSBgUyyKSjP/UK9C5QsuGrs9rETzxjkXA bQzIO195RJBmwBnXAb4ZRT4fRC0sG82WYMpiMOZx0aoZqJ1SqMeFV4vEG9SCc8Nl39JQVEhWdA03e DTE5yHTQ==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8iqG-0002He-GO; Thu, 20 Aug 2020 11:34:48 +0000 Date: Thu, 20 Aug 2020 12:34:48 +0100 From: Matthew Wilcox To: Gao Xiang Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Carlos Maiolino , Eric Sandeen , "Huang, Ying" , Yang Shi , Rafael Aquini , Dave Chinner , stable Subject: Re: [PATCH v2] mm, THP, swap: fix allocating cluster for swapfile by mistake Message-ID: <20200820113448.GM17456@casper.infradead.org> References: <20200820045323.7809-1-hsiangkao@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200820045323.7809-1-hsiangkao@redhat.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 20, 2020 at 12:53:23PM +0800, Gao Xiang wrote: > SWP_FS is used to make swap_{read,write}page() go through > the filesystem, and it's only used for swap files over > NFS. So, !SWP_FS means non NFS for now, it could be either > file backed or device backed. Something similar goes with > legacy SWP_FILE. > > So in order to achieve the goal of the original patch, > SWP_BLKDEV should be used instead. This is clearly confusing. I think we need to rename SWP_FS to SWP_FS_OPS. More generally, the swap code seems insane. I appreciate that it's an inherited design from over twenty-five years ago, and nobody wants to touch it, but it's crazy that it cares about how the filesystem has mapped file blocks to disk blocks. I understand that the filesystem has to know not to allocate memory in order to free memory, but this is already something filesystems have to understand. It's also useful for filesystems to know that this is data which has no meaning after a power cycle (so it doesn't need to be journalled or snapshotted or ...), but again, that's useful functionality which we could stand to present to userspace anyway. I suppose the tricky thing about it is that working on the swap code is not as sexy as working on a filesystem, and doing the swap code right is essentially writing a filesystem, so everybody who's capable already has something better to do. Anyway, Gao, please can you submit a follow-on patch to rename SWP_FS?