Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1691145rwd; Mon, 15 May 2023 01:24:41 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5vLCH5zVrEqJqGcP2D7D+ApQlY7C5J7TebgZgBgH95zSyRZs7Zpl2PygZ5Je5smSq8NKNL X-Received: by 2002:a05:6a21:3281:b0:ff:b9c4:a0aa with SMTP id yt1-20020a056a21328100b000ffb9c4a0aamr4934988pzb.48.1684139080763; Mon, 15 May 2023 01:24:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684139080; cv=none; d=google.com; s=arc-20160816; b=EK5HQ97oIuBaJ77UCkvl2CMrR5zad4vXaJJ947mcCTLmvtXCvLndstCAoUGUS5v+2S Utl6kVXEFsn754Z0cJNjytTyDaXjQmuB9XZvw2xzg75XnzOHcMWPqcgdh0H0Ybj61Vv+ sRGRff/9nfDbXZjkhB0ALZTHpbznd5MShdloVN1MainOJImknyo6rDaP/evqxj5+Gxqm 2UdA3FXQp3vMi/1tO7qnzlwMVdGhLrVwhKTlpfkT0Bcoxb9pNSeKBycgFwbJkUR1Cm0E cDiFCkUP+eJAu42ZN9YEGj3pfrD576TAjNvFQzZq9NwZ1UMKv5VMWjqxa20EBluzLjJN xUbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id; bh=GLfqaQmDgMO1CLrDb0n3WgV7Az0CJJmg8AYKBUxQadQ=; b=bHrIymtr0UPqe76fhibG/XrqurZEEInQIDvxpDcVWkvU9VmiCf+4842x9v7LeHaj2o ide9G67mGR63MazjYM/h7JoOEZiOZeOmW1S7iRQZXwW8hqgPqCum6ZaNxblBtIJLijOZ tabyOREhS4p0a7nxGlpBIHlNUwKxTAo8uxN+zB+OuU+yyDJQpGk3eQJVXZv57PA/qjIY Q9up/lUEc86CPQ3+MWQW9tMKkIxobIMewvj6EvBwtyXnMwXurA314WnNdIuoVc+z5t8d sqUfLlPr7tWarnOREJdbEnWl9U70jCChf/4Gfg8CMCZapNTG+L7EFftNVW/bzgezRM7R DMhA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c18-20020a637252000000b00528d30e698bsi15741603pgn.734.2023.05.15.01.24.28; Mon, 15 May 2023 01:24:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239784AbjEOH6i (ORCPT + 99 others); Mon, 15 May 2023 03:58:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239693AbjEOH63 (ORCPT ); Mon, 15 May 2023 03:58:29 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B8B20171F; Mon, 15 May 2023 00:55:38 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CCC472F4; Mon, 15 May 2023 00:56:22 -0700 (PDT) Received: from [10.57.83.208] (unknown [10.57.83.208]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 830B33F67D; Mon, 15 May 2023 00:55:35 -0700 (PDT) Message-ID: <89ad5070-db72-7bf1-5d86-a89fea54e789@arm.com> Date: Mon, 15 May 2023 08:55:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v4 1/4] devres: Provide krealloc_array To: Greg KH Cc: linux-kernel@vger.kernel.org, linux@roeck-us.net, michal.simek@amd.com, Jonathan.Cameron@huawei.com, Jonathan Corbet , Jean Delvare , Anand Ashok Dumbre , Jonathan Cameron , Lars-Peter Clausen , Andy Gross , Bjorn Andersson , Konrad Dybcio , Jiri Slaby , linux-doc@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-serial@vger.kernel.org References: <20230509094942.396150-1-james.clark@arm.com> <20230509094942.396150-2-james.clark@arm.com> <2023051340-sinuous-darkroom-2497@gregkh> Content-Language: en-US From: James Clark In-Reply-To: <2023051340-sinuous-darkroom-2497@gregkh> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/05/2023 12:04, Greg KH wrote: > On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote: >> There is no krealloc_array equivalent in devres. Users would have to >> do their own multiplication overflow check so provide one. >> >> Reviewed-by: Jonathan Cameron >> Signed-off-by: James Clark >> --- >> Documentation/driver-api/driver-model/devres.rst | 1 + >> include/linux/device.h | 11 +++++++++++ >> 2 files changed, 12 insertions(+) >> >> diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst >> index 4249eb4239e0..8be086b3f829 100644 >> --- a/Documentation/driver-api/driver-model/devres.rst >> +++ b/Documentation/driver-api/driver-model/devres.rst >> @@ -364,6 +364,7 @@ MEM >> devm_kmalloc_array() >> devm_kmemdup() >> devm_krealloc() >> + devm_krealloc_array() >> devm_kstrdup() >> devm_kstrdup_const() >> devm_kvasprintf() >> diff --git a/include/linux/device.h b/include/linux/device.h >> index 472dd24d4823..58f4f5948edb 100644 >> --- a/include/linux/device.h >> +++ b/include/linux/device.h >> @@ -223,6 +223,17 @@ static inline void *devm_kcalloc(struct device *dev, >> { >> return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO); >> } >> +static inline __realloc_size(3, 4) void * __must_check > > Shouldn't you have a blank line before this one? I was going for consistency with the rest of this section which doesn't have newlines between the functions for some reason. I can add one and resubmit but it might look a bit out of place? > >> +devm_krealloc_array(struct device *dev, void *p, size_t new_n, size_t new_size, gfp_t flags) >> +{ >> + size_t bytes; >> + >> + if (unlikely(check_mul_overflow(new_n, new_size, &bytes))) >> + return NULL; >> + >> + return devm_krealloc(dev, p, bytes, flags); >> +} > > I dislike how we have to keep copying the "real" functions (i.e. > krealloc_array) into something like this, but I can't think of a better > way to do it. > Maybe something could be done with some macro magic, but it would probably end up being worse than just copying them and would affect the real ones as well. So yeah I can't think of any easy gains either. Thanks James > thanks, > > greg k-h