Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp7063758imm; Tue, 24 Jul 2018 07:52:03 -0700 (PDT) X-Google-Smtp-Source: AAOMgpesVACAvUDb5604zjg5ecGIQLij/LvCs9JTx3LmUdr64HHqjXO5utFHHqkaxw6jHlfpGocE X-Received: by 2002:a17:902:7e06:: with SMTP id b6-v6mr17272061plm.230.1532443923508; Tue, 24 Jul 2018 07:52:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532443923; cv=none; d=google.com; s=arc-20160816; b=iW62bUA/NrQCij6Lc/xSIcl0R/26en7SB6Y1aMhUzhBlyqYwGis9BPy6gNkEZjW8R0 RsI7l82tg765mCGBY0htt6axCWkrFlhsGBxyobyHlg6zRPgl5m92X/mrEBUlTUPZTYyL T8/lEBIXCqQ7wLUKDYvMojeomMSQdfU08OBQ3eH/GBCUXq15B/XnVmaiZOPAmeA7C76Y TAfQkEBOykJ8dPZSGIG5ZwlQu5jCbxtkLI/9pUX+wRuZzEfUgrsWofNIHrteKQqXON9S 0xCviYKxu7V+eUfoehPCxol6qK0LNNJ5cFxXLPaet6RjFQM9za6k5XFxepy5b88Veoue jPXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=K2ULUtOv36NWt1CCFwxh1wA9HaBjaKSZDSxsJ4R6Z/k=; b=mRrFZpONoYA2uk/8EB+AgWX8o5Gp6f+dtg3H3KU/bMwnHigmE2/kS9YZmn+21hFNQi Vf5HZs7TApupuJATSEcXHca2MoGyHqO9DvqB+uihALXzPMKXGV2ZlKASweZBlbbvHFZM Ne05ChHS2fT1yWaMNGxYviFRUGL0pgtZEm5qFzMFlBk3/W1BWPRQNlhpSA2z/NDAPkXO qGOh0MaNc6NM3h354z5SxCt5CkYt7p0rhQ/6or5hkumAwlCK3P967wV57omaRcyUu/aP l4ZUoceYaJIvawjQp5k4QE5VZ0XPCuiR4Dp4sUIW9re2ZTEHZLPoEawhMtlYQnJ296Zd Ihiw== ARC-Authentication-Results: i=1; mx.google.com; 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 f17-v6si11751834pgl.59.2018.07.24.07.51.48; Tue, 24 Jul 2018 07:52:03 -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; 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 S2388617AbeGXP5G (ORCPT + 99 others); Tue, 24 Jul 2018 11:57:06 -0400 Received: from mga07.intel.com ([134.134.136.100]:65101 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388564AbeGXP5G (ORCPT ); Tue, 24 Jul 2018 11:57:06 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2018 07:50:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,398,1526367600"; d="scan'208";a="60261576" Received: from theros.lm.intel.com (HELO linux.intel.com) ([10.232.112.164]) by orsmga006.jf.intel.com with ESMTP; 24 Jul 2018 07:50:13 -0700 Date: Tue, 24 Jul 2018 08:50:13 -0600 From: Ross Zwisler To: Huaisheng Ye Cc: linux-nvdimm@lists.01.org, dan.j.williams@intel.com, ross.zwisler@linux.intel.com, willy@infradead.org, vishal.l.verma@intel.com, dave.jiang@intel.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, viro@zeniv.linux.org.uk, martin.petersen@oracle.com, axboe@kernel.dk, gregkh@linuxfoundation.org, bart.vanassche@wdc.com, jack@suse.cz, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-fsdevel@vger.kernel.org, chengnt@lenovo.com, Huaisheng Ye Subject: Re: [PATCH 0/5] Do not request a pointer kaddr when not required Message-ID: <20180724145013.GA19466@linux.intel.com> Mail-Followup-To: Ross Zwisler , Huaisheng Ye , linux-nvdimm@lists.01.org, dan.j.williams@intel.com, willy@infradead.org, vishal.l.verma@intel.com, dave.jiang@intel.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, viro@zeniv.linux.org.uk, martin.petersen@oracle.com, axboe@kernel.dk, gregkh@linuxfoundation.org, bart.vanassche@wdc.com, jack@suse.cz, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-fsdevel@vger.kernel.org, chengnt@lenovo.com, Huaisheng Ye References: <20180724084510.6104-1-yehs2007@zoho.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180724084510.6104-1-yehs2007@zoho.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 24, 2018 at 04:45:05PM +0800, Huaisheng Ye wrote: > From: Huaisheng Ye > > Some functions within fs/dax and dax/super don't need to get kaddr from > direct_access. Assigning NULL to kaddr to ->direct_access() is more > straightforward and simple than offering a useless local pointer. > > So all direct_access() need to check the validity of second rank pointer > kaddr for NULL assignment. If kaddr equals to NULL, it doesn't need to > calculate its value. > > * This series are supplement to [PATCH v2 00/14]mm: Asynchronous + > multithreaded memmap init for ZONE_DEVICE. [1] > > [1]: https://lkml.org/lkml/2018/7/16/828 This whole series looks good to me. Just a few comments: 1) Does this series actually depend on the "Asynchronous multithreaded mmap init for ZONE_DEVICE" series from Dan? It seems totally independent to me? I reviewed yours by applying to linux/master, which worked fine. I ask because Dan's series has been delayed to after v4.19, and if yours isn't actually dependent it could possibly go in sooner. 2) I agree with Christian's comment that the changelogs could be improved slightly. Remember that the goal of the changelog isn't to describe *what* the code is doing, but *why*. We can read that the code now checks if 'kaddr' is NULL, and if so we don't calculate it. It's useful to say that callers may have no need for 'kaddr', so this patch is prep for allowing them to pass in NULL instead of having to pass in a pointer that they then just throw away. 3) I think you should make one more change to kill the unused 'dummy_addr' variable in persistent_memory_claim(). That was the one last case of a dummy 'kaddr' type variable that I could find.