From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE389C4363A for ; Fri, 30 Oct 2020 10:57:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8D24920739 for ; Fri, 30 Oct 2020 10:57:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726434AbgJ3K5f (ORCPT ); Fri, 30 Oct 2020 06:57:35 -0400 Received: from mga06.intel.com ([134.134.136.31]:24804 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725948AbgJ3K5e (ORCPT ); Fri, 30 Oct 2020 06:57:34 -0400 IronPort-SDR: HSpWwG8ejSARafSDwCtr9AQP+Bghg+5FEGYndrQAlzlkTfbnw4MLZQY+gtO9QwXXsZXAmRXdlF LBr0rhmrwoYg== X-IronPort-AV: E=McAfee;i="6000,8403,9789"; a="230225578" X-IronPort-AV: E=Sophos;i="5.77,433,1596524400"; d="scan'208";a="230225578" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2020 03:57:33 -0700 IronPort-SDR: rL+b36wdeO4Dyvcky/eu86oR89lNAHQ9SZWlYgIKzLNjNwq8EDlVylgO92Q5L8N7pxE7NPDR4F /dGSJuOMiX2g== X-IronPort-AV: E=Sophos;i="5.77,433,1596524400"; d="scan'208";a="469490885" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2020 03:57:32 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1kYS78-001xlT-P1; Fri, 30 Oct 2020 12:58:34 +0200 Date: Fri, 30 Oct 2020 12:58:34 +0200 From: Andy Shevchenko To: Bartosz Golaszewski Cc: Greg Kroah-Hartman , "Rafael J . Wysocki" , Linux Kernel Mailing List , Bartosz Golaszewski Subject: Re: [PATCH] devres: zero the memory in devm_krealloc() if needed Message-ID: <20201030105834.GL4077@smile.fi.intel.com> References: <20201026122728.8522-1-brgl@bgdev.pl> <20201026131427.GF4077@smile.fi.intel.com> <20201030105706.GK4077@smile.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201030105706.GK4077@smile.fi.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 30, 2020 at 12:57:06PM +0200, Andy Shevchenko wrote: > On Fri, Oct 30, 2020 at 10:03:50AM +0100, Bartosz Golaszewski wrote: > > On Thu, Oct 29, 2020 at 9:05 PM Andy Shevchenko > > wrote: > > > > > > On Mon, Oct 26, 2020 at 01:27:28PM +0100, Bartosz Golaszewski wrote: > > > > From: Bartosz Golaszewski > > > > > > > > If we're returning the same pointer (when new size is smaller or equal > > > > to the old size) we need to check if the user wants the memory zeroed > > > > and memset() it manually if so. > > > > > > Any use case? Because to me it sounds contradictory to the whole idea of [k]realloc(). > > > > This is kind of a gray area in original krealloc() too and I want to > > submit a patch for mm too. Right now krealloc ignores the __GFP_ZERO > > flag if new_size <= old_size but zeroes the memory if new_size > > > old_size. > > > This should be consistent - either ignore __GFP_ZERO or > > don't ignore it in both cases. I think that not ignoring it is better > > - if user passes it then it's for a reason. > > Sorry, but I consider in these two choices the best is the former one, i.e. > ignoring, because non-ignoring for sizes less than current is counter the > REalloc() by definition. > > Reading realloc(3): > > "If the new size is larger than the old size, the added memory will not be > initialized." > > So, supports my choice over yours. Two notes: - perhaps kzrealloc() for what you want - there is a library call reallocarray() which supports your idea about krealloc_array() API in kernel. -- With Best Regards, Andy Shevchenko