Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp9483ybg; Thu, 11 Jun 2020 15:33:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1Si1F8sYxo5pXBgdDYWdi9zGgRKXhvPAXimwEGbOpCpCCPAwGnzXZfGJvB2gO5urEBsGA X-Received: by 2002:a17:907:1104:: with SMTP id qu4mr9256472ejb.382.1591914826436; Thu, 11 Jun 2020 15:33:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591914826; cv=none; d=google.com; s=arc-20160816; b=BUnJCQWAGcZ9VtfrpC/oPl6mlsY/9yvS53bbamYoauo6IhlgCXJVz3PL6rpFXNFSa2 AK7xPUkNFxAfWu6fwNam2FvmSryOVKyN0EGbdv8f0fuurE8JCPzmxQE8sCld75pSyec8 7dwAZIweptNfMXh3ObL61IT9j+FxCyXfCmVO0aEfludcNLbdlC9UaTfhAFoceJBB2c+S uM7PR5xDxE5aZ03RIl9VRZh4IEuTIa3mgTGrWpRA4+g0bi/nT3eN5jTGyhQeLM3tEg+o VtQWsyFNX4qisXI1DUwytzT5ztBV/NYDKFRQIjIGfBLZ+V7f7C48fGORNCBi7Qb+bY2M ehEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :subject:cc:to:from:date:dkim-signature; bh=+EahI0YlQUT1/wBvgRJFQZcHP3obsCOagtKe7ySyhrM=; b=CzKxEp+p+Dj/yl33iaqZfJL/KJbCeKOolyvYLL4UrGYduiZ9VhVuFMgEpFE0eIpohm xGgGE7GfBf5ngfL7osLUYSTxhqei29AKSDWC3uehWxRQIqpYTOxLdqc2pFL6uvq+4W+M adOiW+kO9SVOrAmmjEDGa7S17as0qz6nNHuurwWQ4+J2Egwax06XJMaffRdBKlXJg1zT jDnIS3CJLkEx9X7GhSfM8I1xfjQYuXyvN+kqZ7bbW5iHf0H5Xx0++v18DDpRecbGAEXM LHAF+QRnkl+oLSSGMCsNVMmmb2BEn60HQ1VMXIc1TZstKZ+iRs0CUWXthqnOnjXR85gP tkjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=W26cncJy; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q10si2395803edn.10.2020.06.11.15.33.24; Thu, 11 Jun 2020 15:33: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; dkim=pass header.i=@google.com header.s=20161025 header.b=W26cncJy; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726317AbgFKWat (ORCPT + 99 others); Thu, 11 Jun 2020 18:30:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726159AbgFKWat (ORCPT ); Thu, 11 Jun 2020 18:30:49 -0400 Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A657C03E96F for ; Thu, 11 Jun 2020 15:30:49 -0700 (PDT) Received: by mail-ot1-x342.google.com with SMTP id t6so5843932otk.9 for ; Thu, 11 Jun 2020 15:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:user-agent:mime-version; bh=+EahI0YlQUT1/wBvgRJFQZcHP3obsCOagtKe7ySyhrM=; b=W26cncJyLH/i2zSIOMrO837pRs3uf2BxQU7IzrLdCgttozbazIeNDlQgCyQFiYpUyY Ms4olROFTxfvmQAdemlh52vDy0Ftr89GQMQrDXOir38oNwY8+8gPiDMnQChh/qPvfhj1 iUsIdILczYmCpO1xqBDBaFflxA4qJYGotgpCt1+gBdruUxe14ckzTnM3+9z+NR3Qkckp 8bXFzj6IhT3p8E6ZtAmnlH8HwiB/X34paleeTrwi7sO8xUPY1QHO1EqXGNShfQxJUmTK oNomeUpR4hUAyI5seihocIFNBhP5T0Ojn22FOBFdo6AgdYqo+CShth6zOvtf4oEc8vZn S8fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:user-agent :mime-version; bh=+EahI0YlQUT1/wBvgRJFQZcHP3obsCOagtKe7ySyhrM=; b=KrHD7GYep+OPisuPFnaPrCxlg52xrVjA/GSK0XJ4V/fanH0TCTKWNrvu6dHRmRX/2B 6VEaXrZj9PqSoiuZu9KvL8pZAeXkzZPGDh9XEzWGt4DapYrMtwuccV5ShsBkGpkDOP2J 66u7q0Jl1+UhOv85H07WDP8t3tKrhAKc6Ohy4d8MDI5k7Zh8yCq0qdZb9O9M7eDUBWPR Xs2k/ux14wZUYEE2yYKsFrdpErRniJUFZ/skXt8n6bIVUj71QEyF3MxbYHvJR4KBGfIS eL2MYnPdXZ8TKncYLCR26S+g9GGWI9O2gASwac5QFYkxvZUorzoPGEbw9JKcooDZ5qDi 6zaw== X-Gm-Message-State: AOAM531/vWuiOZ9dylbE6zeDYqT1tDkgrIEgLIXNZ7i10qpYk1UNREkL xnKIXbgTtlBleLcb30nmDa1UWg== X-Received: by 2002:a05:6830:1dba:: with SMTP id z26mr8682022oti.180.1591914648150; Thu, 11 Jun 2020 15:30:48 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id r15sm978948oot.5.2020.06.11.15.30.45 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 11 Jun 2020 15:30:47 -0700 (PDT) Date: Thu, 11 Jun 2020 15:30:45 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Alex Shi cc: akpm@linux-foundation.org, mgorman@techsingularity.net, tj@kernel.org, khlebnikov@yandex-team.ru, daniel.m.jordan@oracle.com, yang.shi@linux.alibaba.com, willy@infradead.org, hannes@cmpxchg.org, lkp@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, shakeelb@google.com, iamjoonsoo.kim@lge.com, richard.weiyang@gmail.com Subject: [PATCH alexv12 2/2] mm/compaction: fix call to __isolate_lru_page_prepare() Message-ID: User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org isolate_migratepages_block() is calling __isolate_lru_page_prepare() at a point when it has not yet acquired a reference to the page, and may not yet hold the right lruvec lock: it has no hold on the page. trylock_page() is not safe to use at this time: its setting PG_locked can race with the page being freed or allocated ("Bad page"), and can also erase flags being set by one of those "sole owners" of a freshly allocated page who use non-atomic __SetPageFlag(). Though I have tried rcu_read_lock() instead of trylock_page() there (like in page_evictable()), 054f1d1faaed ("mm/swap_state.c: simplify total_swapcache_pages() with get_swap_device()") stopped the freeing of swapper_spaces by RCU; and races against setting PageSwapCache, and the dereference of mapping->a_ops, and the lack of any page reference: all make that a more dubious approach. Just move the call to __isolate_lru_page_prepare() after the call to get_page_unless_zero(), when using trylock_page() has become safe (safe given __isolate's check for PageLRU - unsafe without that). Signed-off-by: Hugh Dickins --- I had envisaged this as a separate patch; but once it came down to just moving the call inside isolate_migratepages_block(), it's probably best folded into 10/16 or 12/16 (needs isolate_fail_put). I shall probably want to come along later, to clean up or eliminate __isolate_lru_page_prepare(): which I found before to have almost nothing in common between its use by isolate_migratepages_block() and its use by isolate_lru_pages(). We can then do its safer checks before the get_page_unless_zero(). But trying that cleanup right now would just get in the way of this series. mm/compaction.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- alexv12/mm/compaction.c 2020-06-11 13:48:10.437046025 -0700 +++ hughd/mm/compaction.c 2020-06-11 13:49:05.570579095 -0700 @@ -960,9 +960,6 @@ isolate_migratepages_block(struct compac if (!(cc->gfp_mask & __GFP_FS) && page_mapping(page)) goto isolate_fail; - if (__isolate_lru_page_prepare(page, isolate_mode) != 0) - goto isolate_fail; - /* * Be careful not to clear PageLRU until after we're * sure the page is not being freed elsewhere -- the @@ -971,6 +968,9 @@ isolate_migratepages_block(struct compac if (unlikely(!get_page_unless_zero(page))) goto isolate_fail; + if (__isolate_lru_page_prepare(page, isolate_mode) != 0) + goto isolate_fail_put; + /* Try isolate the page */ if (!TestClearPageLRU(page)) goto isolate_fail_put;