linux-kernel - Re: [PATCH v3 1/3] devres: provide devm

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]

Message-ID: <CAHp75VfTDmyWWxAAky-CmuvO2ge0T1q+woJ8MxjdRQqNJwHS4w@mail.gmail.com>
Date:   Sat, 11 Jul 2020 18:08:24 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Bartosz Golaszewski <brgl@...ev.pl>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Michal Simek <michal.simek@...inx.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Guenter Roeck <linux@...ck-us.net>,
        linux-iio <linux-iio@...r.kernel.org>,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH v3 1/3] devres: provide devm_krealloc()

On Fri, Jul 10, 2020 at 7:17 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
>
> From: Bartosz Golaszewski <bgolaszewski@...libre.com>
>
> Implement the managed variant of krealloc(). This function works with
> all memory allocated by devm_kmalloc() (or devres functions using it
> implicitly like devm_kmemdup(), devm_kstrdup() etc.).
>
> Managed realloc'ed chunks can be manually released with devm_kfree().

...

>    devm_kfree()
>    devm_kmalloc()
>    devm_kmalloc_array()
> +  devm_krealloc()
>    devm_kmemdup()
>    devm_kstrdup()
>    devm_kvasprintf()

Order?

...

> +void *devm_krealloc(struct device *dev, void *ptr, size_t new_size, gfp_t gfp)

Do we really need the 'new_' prefix in the parameter?

> +{
> +       struct devres *old_dr, *new_dr;
> +       struct list_head old_head;
> +       unsigned long flags;
> +       void *ret = NULL;
> +       size_t tot_size;

tot -> total.

> +
> +       if (unlikely(!new_size)) {
> +               devm_kfree(dev, ptr);
> +               return ZERO_SIZE_PTR;
> +       }

I guess here we need a comment of the possibilities below to have
ZERO_SIZE_PTR as input.

> +       if (unlikely(ZERO_OR_NULL_PTR(ptr)))
> +               return devm_kmalloc(dev, new_size, gfp);
> +
> +       if (WARN_ON(is_kernel_rodata((unsigned long)ptr)))
> +               /*
> +                * We cannot reliably realloc a const string returned by
> +                * devm_kstrdup_const().
> +                */
> +               return NULL;
> +
> +       if (!check_dr_size(new_size, &tot_size))
> +               return NULL;
> +
> +       spin_lock_irqsave(&dev->devres_lock, flags);
> +
> +       old_dr = find_dr(dev, devm_kmalloc_release, devm_kmalloc_match, ptr);

> +       if (WARN_ON(!old_dr))

Under spin lock? I would rather see spin unlock followed by WARN.

> +               /* Memory chunk not managed or managed by a different device. */
> +               goto out;
> +
> +       old_head = old_dr->node.entry;
> +
> +       new_dr = krealloc(old_dr, tot_size, gfp);
> +       if (!new_dr)
> +               goto out;
> +
> +       if (new_dr != old_dr)
> +               list_replace(&old_head, &new_dr->node.entry);
> +
> +       ret = new_dr->data;
> +
> +out:
> +       spin_unlock_irqrestore(&dev->devres_lock, flags);
> +       return ret;
> +}

-- 
With Best Regards,
Andy Shevchenko