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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03B72C28D13 for ; Mon, 22 Aug 2022 16:54:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8EC6F8D0003; Mon, 22 Aug 2022 12:54:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 89C088D0001; Mon, 22 Aug 2022 12:54:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78B3A8D0003; Mon, 22 Aug 2022 12:54:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6C3698D0001 for ; Mon, 22 Aug 2022 12:54:28 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 448091A1343 for ; Mon, 22 Aug 2022 16:54:28 +0000 (UTC) X-FDA: 79827827016.15.6EE575B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf25.hostedemail.com (Postfix) with ESMTP id 61419A0107 for ; Mon, 22 Aug 2022 16:52:40 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7738E61213; Mon, 22 Aug 2022 16:52:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 417EEC433C1; Mon, 22 Aug 2022 16:52:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661187158; bh=ua+EemPhFEiGOECa+PnGXwOWqdK9IkIdgInQOv3c9K0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pT3kjSF+QEXT8O0OlO59j9zM4jtb5K+UdzgN4uZwb6n7hQxauBiQTUmCHt2VMwzqr SusENy0EE1NXLTK6z9oSNdwZtUQf8R/7h5jqy11FkaA1h1sC8QePF6tcB9quDtDW8J MhqAxXyh3uOO7SxMbBDKlBv1b0CQfSHSti6zsJJi5SuWjtKZ9NXM9S8ijxPGQEI1CX dzuSFdu7pnqtof3txRVzo1VWUOAtkX/xYfp6ybd99DysZjxdwYbEvP9ZsYgNkY+4NF ITyrI3vi6t3q9ZOz47VUjgkvNhseZ1nEkBI0wgBcdPjuC5ir7Z8yDQnE81HHAZSIfO o9qxptSAMLHfQ== From: SeongJae Park To: Greg KH Cc: SeongJae Park , akpm@linux-foundation.org, badari.pulavarty@intel.com, damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v3] mm/damon/dbgfs: avoid duplicate context directory creation Date: Mon, 22 Aug 2022 16:52:36 +0000 Message-Id: <20220822165236.87421-1-sj@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pT3kjSF+; spf=pass (imf25.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661187160; a=rsa-sha256; cv=none; b=SZxLVoGhsyHTESzB45/cqv0lt6C4cTnTYYuzekD0VqQdUWTz6wDMg/5Xjfa5fbuyPFIoei QybccqKOFbJGoQrxjwx1x4Jf2uIionpQV3m1eeK/BtfpO0F97RgXvkvPlv+fnDCe6tjZx9 zaOVWM8qup9MMr/vJ6vvI5tFPBuvCPU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661187160; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=F0W5VmI13Jx2XTMIID0Uf85Vz8OHZ3Ep4frjpEntIog=; b=uz209fczxR73N15ZSiaxXqCE3MZYFqBgyAamuiIT2sRaIW+0rUFTsqUFozxjnOMxTGgR93 OoXcutoNuC/ChoYFTjQRBYN/dC9m+3GQcmTWqyczoCG17ztSoIlDv5x5ceJYe9G4j34NXZ egPJTnode+6kAbg/F4DwQ6fytK70fZA= Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pT3kjSF+; spf=pass (imf25.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: 8swx63td6z4jzkrs1nn54z8zw5kt1ssg X-Rspamd-Queue-Id: 61419A0107 X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1661187160-986504 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: Hi Greg, On Mon, 22 Aug 2022 08:24:44 +0200 Greg KH wrote: > On Sun, Aug 21, 2022 at 06:08:53PM +0000, SeongJae Park wrote: > > From: Badari Pulavarty > > > > From: Badari Pulavarty > > Twice? My dumb mistake, sorry. Fortunately Andrew fixed the mess on his own before adding this to mm[1]. Thanks, Andrew! [1] https://lore.kernel.org/mm-commits/20220821233916.8FC63C433D6@smtp.kernel.org/ > > > > > When user tries to create a DAMON context via the DAMON debugfs > > interface with a name of an already existing context, the context > > directory creation fails but a new context is created and added in the > > internal data structure, due to absence of the directory creation > > success check. As a result, memory could leak and DAMON cannot be > > turned on. An example test case is as below: > > > > # cd /sys/kernel/debug/damon/ > > # echo "off" > monitor_on > > # echo paddr > target_ids > > # echo "abc" > mk_context > > # echo "abc" > mk_context > > # echo $$ > abc/target_ids > > # echo "on" > monitor_on <<< fails > > > > Return value of 'debugfs_create_dir()' is expected to be ignored in > > general, but this is an exceptional case as DAMON feature is depending > > on the debugfs functionality and it has the potential duplicate name > > issue. This commit therefore fixes the issue by checking the directory > > creation failure and immediately return the error in the case. > > > > Fixes: 75c1c2b53c78 ("mm/damon/dbgfs: support multiple contexts") > > Cc: # 5.15.x > > Signed-off-by: Badari Pulavarty > > Signed-off-by: SeongJae Park > > --- > > Changes from v2 > > (https://lore.kernel.org/damon/20220819171930.16166-1-sj@kernel.org/) > > - Simply check the debugfs_create_dir() return value (Andrew Morton) > > - Put a comment for justifying check of the return value (Greg KH) > > > > Changes from v1 > > (https://lore.kernel.org/damon/DM6PR11MB3978994F75A4104D714437379C679@DM6PR11MB3978.namprd11.prod.outlook.com/) > > - Manually check duplicate entry instead of checking > > 'debugfs_create_dir()' return value > > - Reword commit message and the test case > > > > Seems Badari have some email client issue, so I (SJ) am making this > > third version of the patch based on Badari's final proposal and > > reposting on behalf of Badari. > > > > mm/damon/dbgfs.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/mm/damon/dbgfs.c b/mm/damon/dbgfs.c > > index 51d67c8050dd..3b55a1b219b5 100644 > > --- a/mm/damon/dbgfs.c > > +++ b/mm/damon/dbgfs.c > > @@ -818,6 +818,9 @@ static int dbgfs_mk_context(char *name) > > return -ENOENT; > > > > new_dir = debugfs_create_dir(name, root); > > + /* Below check is required for a potential duplicated name case */ > > + if (IS_ERR(new_dir)) > > + return PTR_ERR(new_dir); > > Did you just leak the memory allocated above this check? It's hard to > determine as you are setting global variables. We re-alloc the metadata arrays for context above for this new context, and we do not re-alloc those in this failure case. So yes, the arrays will have one more item that not really needed and also not really will be used. However, the variable for the array, 'dbgfs_nr_ctxs' is not increased here. Therefore, the arrays will be re-allocated to the proper size when this function or other function that re-alloc the arrays based on 'dbgfs_nr_ctxs' (For example, 'dbgfs_rm_context()') are called. So, though the arrays could have not-really-needed one entry that is only waste of memory, as it's only a small and fixed amount of memory (just one more pointer), and as the unneeded memory will eventually be returned (by a next 'dbgfs_{mk,rm}_context()' call), I think that's no problem. This is what I intended for keeping the logic simple. If I'm missing something, please let me know, though. Thanks, SJ > > thanks, > > greg k-h