linux-kernel - Re: [PATCH v5 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] [day] [month] [year] [list]

Message-ID: <CAMRc=Mcjv9ykTy8BQSzvG_FnpP1s_SyhyTMpV=fZ1U=SJTy-iA@mail.gmail.com>
Date:   Sat, 25 Jul 2020 21:20:43 +0200
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     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>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     linux-iio <linux-iio@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH v5 1/3] devres: provide devm_krealloc()

On Wed, Jul 15, 2020 at 11:25 AM 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().
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@...libre.com>
> ---

[snip!]

> +void *devm_krealloc(struct device *dev, void *ptr, size_t new_size, gfp_t gfp)
> +{
> +       struct devres *old_dr, *new_dr;
> +       struct list_head old_head;
> +       unsigned long flags;
> +       size_t total_size;
> +       void *ret = NULL;
> +
> +       if (unlikely(!new_size)) {
> +               devm_kfree(dev, ptr);
> +               return ZERO_SIZE_PTR;
> +       }
> +
> +       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, &total_size))
> +               return NULL;
> +
> +       spin_lock_irqsave(&dev->devres_lock, flags);
> +
> +       old_dr = find_dr(dev, devm_kmalloc_release, devm_kmalloc_match, ptr);
> +       if (!old_dr) {
> +               spin_unlock_irqrestore(&dev->devres_lock, flags);
> +               WARN(1, "Memory chunk not managed or managed by a different device.");
> +               return NULL;
> +       }
> +
> +       old_head = old_dr->node.entry;
> +
> +       new_dr = krealloc(old_dr, total_size, gfp);

Ugh, I wanted to check up on this patch and, after looking at it now,
realized it's wrong. If the user calls devm_krealloc() with GFP_KERNEL
we may end up sleeping with spinlock taken.

Let me prepare another version.

Bartosz