Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1083030ybz; Fri, 1 May 2020 14:11:43 -0700 (PDT) X-Google-Smtp-Source: APiQypL7dGrElAMOSsrEt2K1x+MAJhfzyEhcKMA8CcE7jwC+hsGczlj9OY8hqQk/b6FSPKFrp5R+ X-Received: by 2002:a50:fc0d:: with SMTP id i13mr4986361edr.280.1588367502720; Fri, 01 May 2020 14:11:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588367502; cv=none; d=google.com; s=arc-20160816; b=EqySlWg7b6yTnLF8rVRowIoF4VZfhXp51aO7JmdNf6aNo0bY5rBAbDKXWgkLpj9AHw 4b4nw6I/JrnjaqNt8v1+ubeq1WImtH4FMlCCLjX//2vB6Va0hv8UbLkfFXQzgnu6/w9E dDoRDIF5dehy4v8XyUPaIdP0tGN3Dv5qAyaiFR71U5dyljDGWnMYflZ9OtcZmROq9ssZ /hMfn/ZqmVD9LQhGSK1/LhVK6KsT4+GY8Gw7wkpwEQx3VoKxMm9MpWpSSQGN97MYR5Na N9XUkw4bgHhqEiZ9EqjP+hoK6Gs5c08Vi8Uwqy9M/SpLzwcuBUKNRMAdAC6pVGh0oaQw HsRA== 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=y8UNBIkOuPDKh7eUaR72RVuUds/2bHEDYXjKslftrCc=; b=v6BqCeaiw/okkVT+jJDJELX/56r1FWvqDj5GgA1+Nik6SQkzOrS0n/MsX3EumCchVZ k/AmIe4QjMMWndHK5nCEdeIpjPW999L0GaiAqavVVDXfWWhDyrV/mCThdyEFv6TRCCGY iYnBG6tycfc9wtMwkXUed+WB0JZ/Fb8h72Mnj6eIwvyLMXJ+pI159J3E27Fr3sv2o96a k4M6RVgFMgS25ZwZRci9UTsA7gQzlBCHo/xcn58aFDdgtRKDFzxIdXYvDHCgUr3mfmkK h7/rOpVm3KScsX3Laa2D+SrzWzhnNoSKBNZvkEKHJsv6qQiWpOgceoLYbaWbe1pgWy+N Npew== 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 c15si2461184ejr.343.2020.05.01.14.11.20; Fri, 01 May 2020 14:11:42 -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 S1726534AbgEAVHA (ORCPT + 99 others); Fri, 1 May 2020 17:07:00 -0400 Received: from mga17.intel.com ([192.55.52.151]:41968 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726045AbgEAVG7 (ORCPT ); Fri, 1 May 2020 17:06:59 -0400 IronPort-SDR: MX5d6yeunNxsVI22BgDOvlnp4Slhvr8XNbPOIDfNgLJsLsOTocBnL102tXO2rV6hK4CVsb2cxW bzb9lgKQEE0g== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 May 2020 14:06:59 -0700 IronPort-SDR: ndrAxZLEU5/DjQqA4yIL2o6b5+ROOEw6B1BXjG7cT6PX4yclHY8sdrTh2h5rSxX9mxT64XJeEI pGW4vEMquB+g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,341,1583222400"; d="scan'208";a="405849459" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.77.144]) by orsmga004.jf.intel.com with ESMTP; 01 May 2020 14:06:59 -0700 Subject: [RFC][PATCH 2/2] mm/migrate: annotate possible unnecessary xas_load() 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:20 -0700 References: <20200501210516.DFAFF456@viggo.jf.intel.com> In-Reply-To: <20200501210516.DFAFF456@viggo.jf.intel.com> Message-Id: <20200501210520.6B29706C@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 The xas_load() in question also originated in "e286781: mm: speculative page references" as a radix_tree_deref_slot(), the only one in the tree at the time. I'm thoroughly confused why it is needed, though. A page's slot in the page cache should be stabilized by lock_page() being held. So, first of all, add a VM_BUG_ON_ONCE() to make it totally clear that the page is locked. But, even if the page was truncated, we normally check: page_mapping(page) != mapping to check for truncation. This would seem to imply that we are looking for some kind of state change that can happen to the xarray slot for a page, but without changing page->mapping. I'm at a loss for that that might be. Stick a WARN_ON_ONCE() in there to see if we ever actually hit this. 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 | 8 ++++++++ 1 file changed, 8 insertions(+) diff -puN mm/migrate.c~remove_extra_xas_load_check mm/migrate.c --- a/mm/migrate.c~remove_extra_xas_load_check 2020-05-01 14:00:43.377525921 -0700 +++ b/mm/migrate.c 2020-05-01 14:00:43.381525921 -0700 @@ -407,6 +407,8 @@ int migrate_page_move_mapping(struct add int dirty; int expected_count = expected_page_refs(mapping, page) + extra_count; + VM_WARN_ONCE(!PageLocked(page)); + if (!mapping) { /* Anonymous page without mapping */ if (page_count(page) != expected_count) @@ -425,7 +427,13 @@ int migrate_page_move_mapping(struct add newzone = page_zone(newpage); xas_lock_irq(&xas); + /* + * 'mapping' was established under the page lock, which + * prevents the xarray slot for 'page' from being changed. + * Thus, xas_load() failure here is unexpected. + */ if (xas_load(&xas) != page) { + WARN_ON_ONCE(1); xas_unlock_irq(&xas); return -EAGAIN; } _