linux-kernel - Re: [PATCH 1/1] device-dax: avoid an unnecessary check in alloc_dev_dax

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 17 Dec 2020 19:10:04 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     Zhen Lei <thunder.leizhen@...wei.com>
Cc:     Vishal Verma <vishal.l.verma@...el.com>,
        Dave Jiang <dave.jiang@...el.com>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Jane Chu <jane.chu@...cle.com>
Subject: Re: [PATCH 1/1] device-dax: avoid an unnecessary check in alloc_dev_dax_range()

On Fri, Nov 20, 2020 at 1:23 AM Zhen Lei <thunder.leizhen@...wei.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