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=-13.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 A18F7C433EF for ; Thu, 16 Sep 2021 00:05:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 54DD161186 for ; Thu, 16 Sep 2021 00:05:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 54DD161186 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 96E306B0071; Wed, 15 Sep 2021 20:05:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 91F08900003; Wed, 15 Sep 2021 20:05:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 80CDD900002; Wed, 15 Sep 2021 20:05:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 730F86B0071 for ; Wed, 15 Sep 2021 20:05:08 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2C44D18025589 for ; Thu, 16 Sep 2021 00:05:08 +0000 (UTC) X-FDA: 78591491496.03.4549978 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf08.hostedemail.com (Postfix) with ESMTP id E241330000B7 for ; Thu, 16 Sep 2021 00:05:07 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 6597D61165; Thu, 16 Sep 2021 00:05:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1631750705; bh=Qe2RhOiF6NH6LAk/j0a+uF0k+epN0Ae/d4fNfyU39sM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HkI85ySY9XO0meXDumSGQ7yGTPMCFpr6wCzufDdlD3bVhYn+1/yz/WERV6/BG5kWu EkujdztHulhKFWJIDJS46nuOHsCM/ZZEJbFhFcRwRfwSZXjuHyo0DMOXt01BzcJjbH JvW/ukfC5HuyiMoCHzSZJmTG97z2U7WJeeky280WXVZ1wpS3yvhYjCCGuKZmOSGjDF zJ/u8rl/nDE4zLGTSCbNQz7QUkufkV0a2vfqFEX/ODv+ICFD8yhEixBGRvADsX7Ouk rMUbYFmQzp/dCXynZxkSXZ7RXtlLsAFqB7oN2M3aHxdKpTe9tGlLAOw58nG7FrMTxN mycwsR65D96gA== Date: Thu, 16 Sep 2021 09:05:03 +0900 From: Masami Hiramatsu To: Steven Rostedt Cc: Linus Torvalds , Mike Rapoport , Andrew Morton , LKML , Ingo Molnar , Linux-MM , Vlastimil Babka Subject: Re: [PATCH v3 3/3] bootconfig: Free xbc_data in xbc_destroy_all() Message-Id: <20210916090503.c9d8209e8c88e9c4c7d3072c@kernel.org> In-Reply-To: <20210915102354.2841798d@oasis.local.home> References: <163171196689.590070.15063104707696447188.stgit@devnote2> <163171199244.590070.6356174550728998874.stgit@devnote2> <20210915102354.2841798d@oasis.local.home> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E241330000B7 X-Stat-Signature: 97df7cty9ucaz6aum6xtq81rcn3jyhqm Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HkI85ySY; spf=pass (imf08.hostedemail.com: domain of mhiramat@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=mhiramat@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1631750707-449680 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 15 Sep 2021 10:23:54 -0400 Steven Rostedt wrote: > On Wed, 15 Sep 2021 22:19:52 +0900 > Masami Hiramatsu wrote: > > > @@ -810,6 +811,8 @@ void __init xbc_destroy_all(void) > > * In error cases, @emsg will be updated with an error message and > > * @epos will be updated with the error position which is the byte offset > > * of @buf. If the error is not a parser error, @epos will be -1. > > + * Note that the @buf ownership is transferred, so it will be freed > > + * in xbc_destroy_all(). > > */ > > int __init xbc_init(char *buf, const char **emsg, int *epos) > > { > > I hate this "ownership transfer". Looking at the use case here: > > init/main.c: > > copy = memblock_alloc(size + 1, SMP_CACHE_BYTES); > if (!copy) { > pr_err("Failed to allocate memory for bootconfig\n"); > return; > } > > memcpy(copy, data, size); > copy[size] = '\0'; > > ret = xbc_init(copy, &msg, &pos); > if (ret < 0) { > > Instead of having xbc_init() return the node count on success, how about > having it allocate the buffer to use and then return it? > > That is, move the: > > copy = memblock_alloc(size + 1, SMP_CACHE_BYTES); > if (!copy) { > pr_err("Failed to allocate memory for bootconfig\n"); > return; > } > > memcpy(copy, data, size); > copy[size] = '\0'; > > into xbc_init(), and have data, and size be passed to it. > > Then, have it return the pointer of "copy" or NULL on error? Thanks for pointing it out, that is also good to me. Let me update it. > > This will keep the semantics of xbc_* owning the buffer that gets > freed by the destroy. > > The xbc_init() could also do the pr_info() that prints the bytes and > node count. There's no other reason to pass that node count to the > caller, is there? Ah, it is my policy that the error or information message is shown by caller (since caller can also ignore that, e.g. passing the testing data), not from the library code. I learned that from perf-probe and ftrace, sometimes the library code reused in unexpected way. So I decided to decouple the generating error message and showing it. Thank you, > > -- Steve -- Masami Hiramatsu