Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp2853584ybc; Wed, 13 Nov 2019 23:29:45 -0800 (PST) X-Google-Smtp-Source: APXvYqytqCGuaGGJG2L2qcPmMhqS1MqukaWAw1qBlLci2bHUs7ZxLv7/mXFEGjTS3Q8lp21OarEH X-Received: by 2002:a17:906:c797:: with SMTP id cw23mr6978745ejb.19.1573716585726; Wed, 13 Nov 2019 23:29:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573716585; cv=none; d=google.com; s=arc-20160816; b=dTfWMTj6EF2/nAnUR+lyAAiF8iOq76sPwFLmH+DSA6q/Tnslqo/DwqZym5bGuq+lQf ej93utrM598c46gdmPXueofNa7t6aW+0iE7gcqHL9g/QXI/2Uc6B46oGRplRdIszRQxV Hussmb3AQOfGLjcRVGtCiZtxxoS2H+9+1O0b74UXntxFWCXNjlj9D3c5cZv63/fQJo6Q QGy7Tex4W1jouukUnml7MLA+xebWRLJN6l3ZewqYmEXAfsnCwi/2ZNw9gipC9QUPWup2 kZ2KR9fGHyQ6mzCBQxrJ+hIMV1QMECF4Zi9qfK5n3ezGgiV3k0UPJZoq/07aOlFf2TzT Y5oA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=f5d5/bpHoXBtRihRqTs8DB3/xqD8D283lsRAFtLbrfY=; b=qUFV2Lz7ThlZv6cDdq58nh5arNqc9NXZHlNJqscjJDuf42TR5/M5aWYnUAnr17RP5e UYQHJuSzvYk19E3WVItHzeXCjTnj1Dhbh43FjZ/28xAgOtQCzHWF4DqEHDHTw5Of4qEn oTR52kWoG0c7oXfZnXVxrwKD68zkWq3/iOcGRVkq76OFAGI+xrHynfHE/tD37kZ0aQcK tjOFkbxz+AKbaLf3iLZh1UVZ1PEPv3WaE8dKArMdKjmlxMnEFTT2jb8EcvUthqWVc+Tw 0XfTl08zQEnisZkmNDUxn0oItrj8GIjqe90XsbGuwUxIK7jBZYAfwBr6k1rpFU7Cu7eZ 2h3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=ka9TFfKo; 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 h43si3410888edb.89.2019.11.13.23.29.20; Wed, 13 Nov 2019 23:29:45 -0800 (PST) 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=ka9TFfKo; 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 S1726977AbfKNHZf (ORCPT + 99 others); Thu, 14 Nov 2019 02:25:35 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:46951 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726410AbfKNHZf (ORCPT ); Thu, 14 Nov 2019 02:25:35 -0500 Received: by mail-oi1-f194.google.com with SMTP id n14so4353136oie.13 for ; Wed, 13 Nov 2019 23:25:34 -0800 (PST) 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; bh=f5d5/bpHoXBtRihRqTs8DB3/xqD8D283lsRAFtLbrfY=; b=ka9TFfKoK65lEg8yCbO74ziezgRtQdVgpXv0yhH69HHcnCDQeoZMEx0zXoBS7PR5CR HUSM9ldvvNqYmMcaebJWojK6kxK8YredJDVlobIurEivs8HOFwov2jkpRQva3FuViGRf ZaqsOLOTzq/jVjwP4ypul0EYWEaO7bvk7hbPzNM96uv6Cgr5HBNYLPmiYoYyOFHvE9hD mXVwpyQKlHtexK/PvqnnO2dznfTmoig1liLGmqjelsl+RrlPIQi/2x1HOJVbWTe4SI/d 3v/ItiNlUzTdLdfu/x+OUPTS84IMvoks4EpIT9ybpTurledVYXiFfLBuX7ocfw5Mez8k y+4Q== 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; bh=f5d5/bpHoXBtRihRqTs8DB3/xqD8D283lsRAFtLbrfY=; b=bjfyLPSWD4a9wdC/iZFbYpF8XQgLtFMGt8shdJRWwg/2YSqc3B4fGvEGfSZe55WZ8R H5HDSyKwvA0vPfOAfvKj4PgtIAuYL3MDcR50SDRmFeyTPSf2wq4mXm2mTQMOoT3/nUA3 lK09mTNJVyaReYW2p6JkVZi0kTfMyJzO3ZRa4plqiNYeVB9AEXg7i0zVEl56Zt4jPXO1 kCp8u2AhQD2WHoZ2VIGCvbchD2+MXm+8gYg8DU0ycqQNY10qDPSaOTiqORVfdZ+F5n6f VZP42vVgjgB+ocgr+XgW2ejVfdd+xTvWHs+IewoT3UxubbGHy5/yCtZjII9rS1HMYbuS 5Q+w== X-Gm-Message-State: APjAAAXPWUvz1UGSAXGVzJRQ44TlEWjMn7PX0TXpNleXhvP5W+LdEsRk GpSACRgxFa1y/ZYfzoj7GOpD/kkPBbRrRGJPBg2vYA== X-Received: by 2002:a05:6808:1da:: with SMTP id x26mr720739oic.149.1573716334479; Wed, 13 Nov 2019 23:25:34 -0800 (PST) MIME-Version: 1.0 References: <157368992671.2974225.13512647385398246617.stgit@dwillia2-desk3.amr.corp.intel.com> <20191114071903.GA26307@lst.de> In-Reply-To: <20191114071903.GA26307@lst.de> From: Dan Williams Date: Wed, 13 Nov 2019 23:25:23 -0800 Message-ID: Subject: Re: [PATCH] mm: Cleanup __put_devmap_managed_page() vs ->page_free() To: Christoph Hellwig Cc: John Hubbard , Jan Kara , Ira Weiny , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , linux-nvdimm , Linux Kernel Mailing List , Linux MM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 13, 2019 at 11:19 PM Christoph Hellwig wrote: > > On Wed, Nov 13, 2019 at 04:07:22PM -0800, Dan Williams wrote: > > static int devmap_managed_enable_get(struct dev_pagemap *pgmap) > > { > > - if (!pgmap->ops || !pgmap->ops->page_free) { > > + if (!pgmap->ops || (pgmap->type == MEMORY_DEVICE_PRIVATE > > + && !pgmap->ops->page_free)) { > > I don't think this check is correct. You only want the the ops null check > or MEMORY_DEVICE_PRIVATE as well now, i.e.: > > if (pgmap->type == MEMORY_DEVICE_PRIVATE && > (!pgmap->ops || !pgmap->ops->page_free)) { > > > @@ -476,10 +471,17 @@ void __put_devmap_managed_page(struct page *page) > > * handled differently or not done at all, so there is no need > > * to clear page->mapping. > > */ > > - if (is_device_private_page(page)) > > - page->mapping = NULL; > > + if (is_device_private_page(page)) { > > + /* Clear Active bit in case of parallel mark_page_accessed */ > > This adds a > 80 char line. But that whole flow of the function seems > rather odd now. > > Why can't we do: > > if (count == 0) { > __put_page(page); > } else if (is_device_private_page(page)) { > __ClearPageActive(page); > __ClearPageWaiters(page); > > mem_cgroup_uncharge(page); > page->mapping = NULL; > page->pgmap->ops->page_free(page); > } else { > wake_up_var(&page->_refcount); > } > All the above looks good to me will spin a v2. > (except for the fact that I don't get the point of calling __put_page > on a refcount of zero, but that is separate from this patch). That looked odd to me as well until I recalled that we did that to simplify the pgmap reference counting. 71389703839e mm, zone_device: Replace {get, put}_zone_device_page() with a single reference to fix pmem crash I'll add a comment in v2.