mm/damon/dbgfs: avoid duplicate context directory creation

PATCH Applied SeongJae Park 2 participants 4 messages Aug 21, 2022 – Aug 23, 2022

Subsystems (3)

Stable branch Memory management DAMON

lore

Share & tools

lore

SeongJae Park

author maintainer

2022-08-21 18:09 UTC #0 lore raw

PATCH v3 1/1 mm/damon/dbgfs: avoid duplicate context directory creation

From: Badari Pulavarty <[email protected]>

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 <[email protected]> # 5.15.x

Signed-off-by Badari Pulavarty <[email protected]>

Signed-off-by SeongJae Park <[email protected]>

---
Changes from v2
(https://lore.kernel.org/damon/[email protected]/)
- 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(+)

mm/damon/dbgfs.c +3 -0

index 51d67c8050dd..3b55a1b219b5 100644
@@ -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);
 	dbgfs_dirs[dbgfs_nr_ctxs] = new_dir;
 
 	new_ctx = dbgfs_new_ctx();

Signature · 1 line

2.25.1

Greg KH

maintainer

2022-08-22 06:24 UTC #1 lore raw

Quoted 3 lines · SeongJae Park

From: Badari Pulavarty <[email protected]>
From: Badari Pulavarty <[email protected]>

Twice?

Quoted 50 lines

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 <[email protected]> # 5.15.x
Signed-off-by Badari Pulavarty <[email protected]>
Signed-off-by SeongJae Park <[email protected]>
---
Changes from v2
(https://lore.kernel.org/damon/[email protected]/)
- 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(+)
mm/damon/dbgfs.c +0 -0
index 51d67c8050dd..3b55a1b219b5 100644

mm/damon/dbgfs.c static int dbgfs_mk_context(char *name) · line 823

Quoted 6 lines

mm/damon/dbgfs.c +3 -0

@@ -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.

thanks,

greg k-h

SeongJae Park

author maintainer

2022-08-22 16:52 UTC #2 lore raw

Hi Greg,

Quoted 6 lines · On Mon, 22 Aug 2022 08:24:44 +0200 Greg KH <[email protected]> wrote:

Quoted 3 lines · SeongJae Park
From: Badari Pulavarty <[email protected]>
From: Badari Pulavarty <[email protected]>
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/[email protected]/

Quoted 53 lines

Quoted 53 lines
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 <[email protected]> # 5.15.x
Signed-off-by Badari Pulavarty <[email protected]>
Signed-off-by SeongJae Park <[email protected]>
---
Changes from v2
(https://lore.kernel.org/damon/[email protected]/)
- 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(+)
mm/damon/dbgfs.c +0 -0
index 51d67c8050dd..3b55a1b219b5 100644
@@ -818,6 +818,9 @@ static int dbgfs_mk_context(char *name)
 		return -ENOENT;
 

Quoted 7 lines

mm/damon/dbgfs.c static int dbgfs_mk_context(char *name) · line 823
Quoted 4 lines
mm/damon/dbgfs.c +3 -0
 	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

Quoted 4 lines

thanks,
greg k-h

Greg KH

maintainer

2022-08-23 06:58 UTC #3 lore raw

Quoted 17 lines · SeongJae Park

Quoted 7 lines
mm/damon/dbgfs.c static int dbgfs_mk_context(char *name) · line 823
Quoted 4 lines
mm/damon/dbgfs.c +3 -0
 	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.

Quoted 7 lines

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.

Ah, that makes more sense, thanks. The code was not obvious in that error paths normally clean up allocations that were done earlier.

All is good.

thanks,

greg k-h