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;
MIME-Version: 1.0
References: <20201120092251.2197-1-thunder.leizhen@huawei.com>
In-Reply-To: <20201120092251.2197-1-thunder.leizhen@huawei.com>
From:   Dan Williams <dan.j.williams@intel.com>
Date:   Thu, 17 Dec 2020 19:10:04 -0800
Message-ID: <CAPcyv4jxgbawSbYF39g857fiDCRmMACr1u-OiSWkz4M0+2UPbQ@mail.gmail.com>
Subject: Re: [PATCH 1/1] device-dax: avoid an unnecessary check in alloc_dev_dax_range()
To:     Zhen Lei <thunder.leizhen@huawei.com>
Cc:     Vishal Verma <vishal.l.verma@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        linux-nvdimm <linux-nvdimm@lists.01.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Jane Chu <jane.chu@oracle.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Nov 20, 2020 at 1:23 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>
> Swap the calling sequence of krealloc() and __request_region(), call the
> latter first. In this way, the value of dev_dax->nr_range does not need to
> be considered when __request_region() failed.

This looks ok, but I think I want to see another cleanup go in first
before this to add a helper for trimming the last range off the set of
ranges:

static void dev_dax_trim_range(struct dev_dax *dev_dax)
{
        int i = dev_dax->nr_range - 1;
        struct range *range = &dev_dax->ranges[i].range;
        struct dax_region *dax_region = dev_dax->region;

        dev_dbg(dev, "delete range[%d]: %#llx:%#llx\n", i,
                (unsigned long long)range->start,
                (unsigned long long)range->end);

        __release_region(&dax_region->res, range->start, range_len(range));
        if (--dev_dax->nr_range == 0) {
                kfree(dev_dax->ranges);
                dev_dax->ranges = NULL;
        }
}

Care to do a lead in patch with that cleanup, then do this one?

I think that might also cleanup a memory leak report from Jane in
addition to not needing the "goto" as well.

http://lore.kernel.org/r/c8a8a260-34c6-dbfc-1f19-25c23d01cb45@oracle.com