Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp141388ybh; Sun, 12 Jul 2020 01:22:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJze343qED658YGBkFvg+tQutt+MzKJ5Gq6XboHCbfzqEISlxM41ElpY36mZh3YA8Bq//nKX X-Received: by 2002:a17:906:c83c:: with SMTP id dd28mr32825594ejb.420.1594542157335; Sun, 12 Jul 2020 01:22:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594542157; cv=none; d=google.com; s=arc-20160816; b=MEpQH+YqHUq2L/BGuHSiFg1o7DKZwraSrdhxD2vc+jz4iv2AFSMOXsIlknbJ1uCWJY ZxIL+Wej7tU7lQawn5131YjGUSrMZP+syglR7/RGxjBFRHeWpv53wGDAjkZy/dv8lZjj mZrQXFYDkngroyxkfMA434sTH2EBR8eNcUsBZbzxWo770HYToWptP4PpJniYml68oEaT 8rrBIYD/b2DKYqxm0jeCBMNUxP73XJ1uGgJqfHzxu8GXf74D0XRcIS8W7GyWZ+yp5wzK 1sVWSUY+mglnSIeNOEmonnLPMyIYY+xFe++ZLf5jTiy0JoUpJqeG8uoOH8voriS9jjpC L30g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=MGwINlQgCbK7cpwpxpZe+If/M4ESfvkJJhKVPhatAlU=; b=KgTXPchKFj7cm1rKk5bQC0eCrWn5lJtwkTIY7nsSA81l+b2exHiNZO490z3jn2fo1/ PqjbnuiqkPxj3UoEM+pelTQZ3XKKGcMvbD2cR/yJJsbUzm5ipQeWXdnxMkFEvSF6HUpz Tt1ZTwpHFEvQEF40Xi11UBvGaPR3xhciJmWGmxKf+yKTTS+GuZaJ8AeWmtUVhXgdpUmU 4rVJ9waApjkwVqXMO1s894uh5c/ErKmfUP8/BviI6gYX/FQamG8wTo/qcSFCLI52dPyq FzHHWX2LGPXnRSjiUj9niW5YkKqdBqGk71APbDYg3zwFjZqqS3niKrsFtXENlIWxejnJ ndXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=jZXCOE48; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v10si7036450edy.595.2020.07.12.01.22.14; Sun, 12 Jul 2020 01:22:37 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=jZXCOE48; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728404AbgGLITW (ORCPT + 99 others); Sun, 12 Jul 2020 04:19:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725974AbgGLITW (ORCPT ); Sun, 12 Jul 2020 04:19:22 -0400 Received: from mail-qv1-xf41.google.com (mail-qv1-xf41.google.com [IPv6:2607:f8b0:4864:20::f41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D172C061794 for ; Sun, 12 Jul 2020 01:19:21 -0700 (PDT) Received: by mail-qv1-xf41.google.com with SMTP id el4so4473319qvb.13 for ; Sun, 12 Jul 2020 01:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MGwINlQgCbK7cpwpxpZe+If/M4ESfvkJJhKVPhatAlU=; b=jZXCOE48SXImaeZdlJiq4vPp0Rp3n7iSLnYs+sdbkaNBou3U17dn5vlwZ8cvUHR0/s fLI8lSGZrhVZK3dsCRSbv3oXaP7hBuws+Kj9p9D7RIWdxPSUlq//EPxVL3ZX1QjrLNuu q4CYd7YKR3uWPPIO4Jb/tIbAhOx1Kog1KQpF+Z/ETHW93Cz58nDZTHT41AoSh+GC8RiR wE+7pp9e/FP+dguSLrnmQgox2i8nVaRFWRn7ZF3G8B3QsHyIA5grkVOM38SmfIewJEjI ++md5hYIkU2X/Yi9dE76+q97eM8lj11obz63zYW/HhAgEvo5MatZsyfZdClmcRu8V1I3 bVDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MGwINlQgCbK7cpwpxpZe+If/M4ESfvkJJhKVPhatAlU=; b=PYF1O3BYUrdFYg54uKr7/ty3HYy5Ewzm4cg7Ti4uGPzFWyiGUJ7SiPlSVHmqpZ30gx afSbd6upoKzz36hpMNSVpzU+b3xt6Z0z5ksN35tfjWgp7ftyZjIlFieJc0mTAs4YLArD n5YBg5+maS1fj7s0DFbnEV4+L9BLVzXO3J2y8BkTvMnsJ2XKqEubdX9eI0WCSraoG3Hv 3jlZgHW0sTgo62XBmRYC2DS065hRh0vTqTFJRMfXgAhlwxfzKgJwr7T+AWVs3hAYmpIm kZUxE3Vm/67NbqcIyy63VksftA4tMRV5vVRV5hd6XiR3o58rWUZeyECSlIg1O+nRnMyz Mb7Q== X-Gm-Message-State: AOAM532XWq+ToEsicJ2rCUQ49/Vu5RlnY6SVElt6F7fI8WR5UeYVIYWP 5BUx7tG+YfRHuNm++YX4vJVKR1iAuLCa3HPu0tIScw== X-Received: by 2002:ad4:4e07:: with SMTP id dl7mr73637317qvb.134.1594541960625; Sun, 12 Jul 2020 01:19:20 -0700 (PDT) MIME-Version: 1.0 References: <20200710161516.11625-1-brgl@bgdev.pl> <20200710161516.11625-2-brgl@bgdev.pl> In-Reply-To: From: Bartosz Golaszewski Date: Sun, 12 Jul 2020 10:19:09 +0200 Message-ID: Subject: Re: [PATCH v3 1/3] devres: provide devm_krealloc() To: Andy Shevchenko Cc: Bartosz Golaszewski , Jonathan Cameron , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Michal Simek , Greg Kroah-Hartman , Guenter Roeck , linux-iio , linux-arm Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 11, 2020 at 5:08 PM Andy Shevchenko wrote: > > On Fri, Jul 10, 2020 at 7:17 PM Bartosz Golaszewski wrote: > > > > From: Bartosz Golaszewski > > > > 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? > I didn't notice these were ordered alphabetically, I thought it was by functionality. > ... > > > +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? > Yes, I think this is a good name for a function that's meant to modify the size of a memory chunk. > > +{ > > + struct devres *old_dr, *new_dr; > > + struct list_head old_head; > > + unsigned long flags; > > + void *ret = NULL; > > + size_t tot_size; > > tot -> total. > Meh, ok. > > + > > + 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. > Better yet: I'll just add a kernel doc for this function. > > + 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. > Yeah, can be done. > > + /* 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 Bartosz