Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1080716ybz; Fri, 1 May 2020 14:08:46 -0700 (PDT) X-Google-Smtp-Source: APiQypLyfNhIrg9xIMwHtIcT6wwyQESZgf3g8HC9JgBEpKZhoEbMCPgapmWjyqPkAy6zxuNfXhsg X-Received: by 2002:a05:6402:319c:: with SMTP id di28mr5432788edb.185.1588367326695; Fri, 01 May 2020 14:08:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588367326; cv=none; d=google.com; s=arc-20160816; b=mqUe5bPstXpm+TuqLInDgJvbGapVwRqQ4bI9s2Qp79SBA0SEJTI8SUzopaQnxlROq/ lT31YSrUUl4+0PrrRCEooWCpAS2v7SWrM0D6bMZUoeJGpcrvufl+8qBtYNT37HkqkFQH 6wwAbZa11ifuECLl8Omy6LbFMhC0uN8PSz02jGSpUoHHY9C/S7UrOWCKPFA9KelKQjVb dwa1nDGOxk9W5Rquoe24poVZ+sgVEfHZWvwGgMOadIrzL1hG2biCiAQPBwGGnWvGtuh1 nAd0lP3KBfn/p/KD2WVM5d9hCkbZtR07RBXUd8N2VQnxRxtNE+7dBM5pynAFFEKWBYSi 3CwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:in-reply-to:references:date :from:cc:to:subject:ironport-sdr:ironport-sdr; bh=M/FzJd28/Hydgz6+Gjd/P25B8Vwudhoo/YDK2v/Amuk=; b=NWHopeQo1fP4M6eVVZZutuhqRMWqbYx0jlQ/SpfzH4ZSldQo8wO4NHHmYhsUT+4u/J YbeDKfEOu55hZyxHAp86AH3zFpoWGp9416TqVfIL6XSmX3wSg2c8D9rX04rv0KCz++uI E3iHsEmPXouYXjKQkQFzf2wkXR8IfkWEwo+BBXvw5kKsBYDXv3TcqYhkODwofAVSqDqn 9jYLzXoDcIs/LWi5i3HV6HRFqMLj4ZXrlbf4Cz1dRVrEXUfE20UdXxm3bsbsmzyO907j C2x8xmP8UeoOsDulj7GU5feD99O2U2ZeGd2eoj1KwUiUDe20h+NDFWOxdV9C3blbf+jF ALlw== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f11si2350718ejb.492.2020.05.01.14.08.23; Fri, 01 May 2020 14:08:46 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726574AbgEAVG6 (ORCPT + 99 others); Fri, 1 May 2020 17:06:58 -0400 Received: from mga12.intel.com ([192.55.52.136]:14691 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726045AbgEAVG5 (ORCPT ); Fri, 1 May 2020 17:06:57 -0400 IronPort-SDR: WEsCdQx7bsWBcp//WeC8GyeyHVdDdmj2SUffVUQxkmi1BHugrqNz2GsyW0G6juDhfZbv1LV1kK SzP+lxI30oXA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 May 2020 14:06:56 -0700 IronPort-SDR: fLz4oPOZC60fv9eFRf6XoS+qjHY6BgQN9a7XdIo1PDtpEPeDxgJAPiz1VJsNXCDCRhxZAcnxfs PJXezy1GJ5+A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,341,1583222400"; d="scan'208";a="433425589" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.77.144]) by orsmga005.jf.intel.com with ESMTP; 01 May 2020 14:06:56 -0700 Subject: [RFC][PATCH 1/2] mm/migrate: remove extra page_count() check To: linux-kernel@vger.kernel.org Cc: Dave Hansen , npiggin@gmail.com, akpm@linux-foundation.org, willy@infradead.org, yang.shi@linux.alibaba.com, linux-mm@kvack.org From: Dave Hansen Date: Fri, 01 May 2020 14:05:18 -0700 References: <20200501210516.DFAFF456@viggo.jf.intel.com> In-Reply-To: <20200501210516.DFAFF456@viggo.jf.intel.com> Message-Id: <20200501210518.DA161B7E@viggo.jf.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Hansen This is not a bug fix. It was found by inspection, but I believe that it is confusing as it stands. First, page_ref_freeze() is implemented internally with: atomic_cmpxchg(&page->_refcount, expected, 0) == expected The "cmp" part of cmpxchg is making sure that _refcount==expected which means that there's an implicit check here, equivalent to: page_count(page) == expected_count This appears to have originated in "e286781: mm: speculative page references", which is pretty ancient. This check is also somewhat dangerous to have here because it might lead someone to think that page_ref_freeze() *doesn't* do its own page_count() checking. Remove the unnecessary check. Signed-off-by: Dave Hansen Cc: Nicholas Piggin Cc: Andrew Morton Cc: Matthew Wilcox (Oracle) Cc: Yang Shi Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org --- b/mm/migrate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN mm/migrate.c~remove_extra_page_count_check mm/migrate.c --- a/mm/migrate.c~remove_extra_page_count_check 2020-05-01 14:00:42.331525924 -0700 +++ b/mm/migrate.c 2020-05-01 14:00:42.336525924 -0700 @@ -425,11 +425,12 @@ int migrate_page_move_mapping(struct add newzone = page_zone(newpage); xas_lock_irq(&xas); - if (page_count(page) != expected_count || xas_load(&xas) != page) { + if (xas_load(&xas) != page) { xas_unlock_irq(&xas); return -EAGAIN; } + /* Freezing will fail if page_count()!=expected_count */ if (!page_ref_freeze(page, expected_count)) { xas_unlock_irq(&xas); return -EAGAIN; _