Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp1169642pxx; Fri, 30 Oct 2020 04:01:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxUInVA18P+4UdYqGOEq02J+0aYn1V7Szqczyr0z2Ri+HQwyzz9dFFgfaW/LF0nALMovl0x X-Received: by 2002:a17:906:a0c2:: with SMTP id bh2mr318855ejb.212.1604055719045; Fri, 30 Oct 2020 04:01:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1604055719; cv=none; d=google.com; s=arc-20160816; b=noXyEOWYQBaZBIZo+mCybgv+Z4Q3P8qjR/UBVJfmSeIEGw1U8LuluX0vO8hWq9DVR+ LOw20Wzcw6t8vFts9bcfwUCCZGf4XsJw6Y8xLKNkONFbnEYBsZ39MAHFN5zXuNFJkclk LFE9yB/2Ddne3/3nFqhb2xXC3WQ6vDpkHxpHpDwQ5O31Yct4sXv6dKyUkoYOTDOvJtBH jHyLwPbOGczTRg4zMJeAJNDshsCJJndjmFsbJp9KdPS6MLpzNKuF8iXaHidhf3XmU/st TzG6CBwuRHXoKIgMBi4a3ARMxtvc33W38STixBt0b37LeKg+okgy3CZ7raR9x+ODiS5v ttrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=jH8EmCd/U6CsfpQC6j/rv3Ef4B08XKGQpoH0pK7NLsQ=; b=IwzBJ3Y+0I6iPo0zYq5hDp08oQEQVLWzxKwao+ZRIF2ybr+MLKcz4CRAkkM6IftsAo xeENh4A3x5cltw4NoxOwi4jBKgqAfISQZkPKW4Sy1f4HhG30o8soy6UMS3c3dAat+TS7 nhfyn+mO6Nvjas+Mm4JJo7qBjRerO51oRw3B+UKP+NRnVUc7ynsIkSMb2MFzv6KaWWq7 HquyPxEX3rXRbLADTgVG27DwR2/vb1VwKGEV8EpjwmXuyNjEkiFDrtHBh/4Z6pTwZ96D BEZ0Pe1KkQc7SiUCKPQj29ca3M3DbKFafipdIVWl+6AbSkRv6yOohM7WXo7FG7l6qsvL NYHA== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ay12si3837313ejb.431.2020.10.30.04.01.36; Fri, 30 Oct 2020 04:01:59 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726226AbgJ3K5f (ORCPT + 99 others); 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