Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp937561ybi; Fri, 24 May 2019 14:06:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqz+bq3PTt4H3COT/nuHJUXyR0lCd8Puar+jyrEKImufhBenXQe16kF+idxHT1ZtUcAk2L3B X-Received: by 2002:a17:902:2beb:: with SMTP id l98mr106858849plb.290.1558731968876; Fri, 24 May 2019 14:06:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558731968; cv=none; d=google.com; s=arc-20160816; b=WyjARcaIMIna3IKZeRm/N4n22fbXfy4N1yv4yWqcnM6iiDGG8aqZtLceKNlYEXV7hX zc+L+O2mdg6HIEozLf62gBYQFyy7/u+uW2cmhL9roUMfZQoaQiP8DQQfbPKTrGXKNd6L gHDvodsdOfjmUBWYRPbMYwGzcN6hwqwmhnHqL2ykudVvzBeIdsAn+ey2Fkh5KJnTF0sx zKymnp8f1OgghiQrYnnaHlV+Boz1TgvytdCwT97oDNlqB666p96BORjUWh+DuXDEzYEa PooayOHdSC741lIcHmkzeaXqJqx7ysBxKSGdBkx3S42PIUo4AL04zijfdI6nv7e8OCRi RJPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=TZLUTKJ3F2aogiV4hxpY25KLHdygnyYYVAPTh5EB7PA=; b=GdC+2oyltM0lYqURX4xiHTTeoZShNePPv7BIJerkpWvLLp+VB3npJS5U0gFcTYzuzI CweRw7mvGWE5xIv1Ll6uaKGFyWQoR2Ud96qMKdKkaOiYc15T1F7p6ax76klzhjP7RZ1X Dl8uedJp/gMNsdw3i12zDnn05uLtwrsV5+suNn6QDhhKzKN9HEELWa+Dgfy+BvUtBtjw xjwoEtO4GTgXp7eNpE8xnaSvHJ7KR3uPfe8vdzRLQD8L7QZbyBQNIiwCDtj4qRKau8GF cojbukDpJGRowc5C/bW0a8YEwtgKcPb8KavCf4bsPx/lRnYvYynKbD2fDr8rM6xsihKf zBbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=SVznC4KC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id n14si5969252pfa.67.2019.05.24.14.05.52; Fri, 24 May 2019 14:06:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=SVznC4KC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S2404182AbfEXVEF (ORCPT + 99 others); Fri, 24 May 2019 17:04:05 -0400 Received: from mail-oi1-f196.google.com ([209.85.167.196]:45276 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727115AbfEXVEF (ORCPT ); Fri, 24 May 2019 17:04:05 -0400 Received: by mail-oi1-f196.google.com with SMTP id w144so8013020oie.12 for ; Fri, 24 May 2019 14:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TZLUTKJ3F2aogiV4hxpY25KLHdygnyYYVAPTh5EB7PA=; b=SVznC4KCLx7YSAx2b6fQ+ZtJiZ6ujYdV9mSMxY84cZ56j+I/vr7lCZ/TTMGPqIrmG2 n+MXhfhPC5SPlCZeuF2ieZOIOLtAiTxsv8dTJ3LY+T++Gx1kU0nnyQjXCoaVyIRN2139 bNjLSLTnsM4vNLAE53uhz0BWJ5+IUfLiAbY/s+oxqkfDD+60ZakSOC4NcjsVb/AdikkC Ep3lJuX0jO9ltkpAJ7esLFb6M7WD0hEd9tkFPAhX3J2Jbb5HOcty+jYUuRdcBSREf+Rw JqYkgRMAVIy/x+dJaSnpwbW1LDzz1JAl9eng+iVqHCNf+jFOWorG+cxdGn6taPp9T4ya Clvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TZLUTKJ3F2aogiV4hxpY25KLHdygnyYYVAPTh5EB7PA=; b=QOQJMeffSueabnyqF9OS9QIVi73TMTSw3t9xPQ49lW3TS3I/vVkJ9tjroi4O8iSHPy YoLlqtnmCxvQ8fkDzMenY+USRdoi/MlYzYgNw8LzAFdIu8hUm2IneYlpm5WqQOEWhDn4 TsjbxIdWyJafyqjqsDDhoA0e+upK94FnRZylIjkX8uD5NSu7ZY6OpzxTiI/3gDmBalDo 42vpyoP6GRubAIaunhUUGBCC+XiybUP3Fx82CooCUd2GWHzLS2XmfdqoHU/EqN5fbziT jBMUC+zPvJRrj8dq8efud/yOiGCrlRkSlzcqz+59O6j4qfBTVORXcs4PY31mOd6H302Q NgIQ== X-Gm-Message-State: APjAAAUCJThDe9vrzpfr9ME7Q1CsvHy6pTqycIrNeifWoQbVPdueOLxa kS3qcrUc8bL7RyxTRlvXK91/NeOKCOud3CrDfIDHSg== X-Received: by 2002:aca:b641:: with SMTP id g62mr7861089oif.149.1558731844633; Fri, 24 May 2019 14:04:04 -0700 (PDT) MIME-Version: 1.0 References: <20190523223746.4982-1-ira.weiny@intel.com> In-Reply-To: From: Dan Williams Date: Fri, 24 May 2019 14:03:52 -0700 Message-ID: Subject: Re: [PATCH] mm/swap: Fix release_pages() when releasing devmap pages To: "Weiny, Ira" Cc: Andrew Morton , Michal Hocko , Linux MM , Linux Kernel Mailing List , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 23, 2019 at 8:58 PM Dan Williams wro= te: > > On Thu, May 23, 2019 at 3:37 PM wrote: > > > > From: Ira Weiny > > > > Device pages can be more than type MEMORY_DEVICE_PUBLIC. > > > > Handle all device pages within release_pages() > > > > This was found via code inspection while determining if release_pages() > > and the new put_user_pages() could be interchangeable. > > > > Cc: J=C3=A9r=C3=B4me Glisse > > Cc: Dan Williams > > Cc: Michal Hocko > > Cc: John Hubbard > > Signed-off-by: Ira Weiny > > --- > > mm/swap.c | 7 +++---- > > 1 file changed, 3 insertions(+), 4 deletions(-) > > > > diff --git a/mm/swap.c b/mm/swap.c > > index 3a75722e68a9..d1e8122568d0 100644 > > --- a/mm/swap.c > > +++ b/mm/swap.c > > @@ -739,15 +739,14 @@ void release_pages(struct page **pages, int nr) > > if (is_huge_zero_page(page)) > > continue; > > > > - /* Device public page can not be huge page */ > > - if (is_device_public_page(page)) { > > + if (is_zone_device_page(page)) { > > if (locked_pgdat) { > > spin_unlock_irqrestore(&locked_pgdat->l= ru_lock, > > flags); > > locked_pgdat =3D NULL; > > } > > - put_devmap_managed_page(page); > > - continue; > > + if (put_devmap_managed_page(page)) > > This "shouldn't" fail, and if it does the code that follows might get > confused by a ZONE_DEVICE page. If anything I would make this a > WARN_ON_ONCE(!put_devmap_managed_page(page)), but always continue > unconditionally. As discussed offline, I'm wrong here. It needs to fall through to put_page_testzero() for the device-dax case, but perhaps a comment for the next time I forget that subtlety.