Signed-off-by: Kassey Li <[email protected]>
---
mm/cma_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/cma_debug.c b/mm/cma_debug.c
index 2e7704955f4f..c3ffe253e055 100644
--- a/mm/cma_debug.c
+++ b/mm/cma_debug.c
@@ -163,7 +163,7 @@ DEFINE_DEBUGFS_ATTRIBUTE(cma_alloc_fops, NULL, cma_alloc_write, "%llu\n");
static void cma_debugfs_add_one(struct cma *cma, struct dentry *root_dentry)
{
struct dentry *tmp;
- char name[16];
+ char name[CMA_MAX_NAME];
scnprintf(name, sizeof(name), "cma-%s", cma->name);
--
2.17.1
On Tue, 19 Jul 2022 17:15:54 +0800 Kassey Li <[email protected]> wrote:
> Signed-off-by: Kassey Li <[email protected]>
> ---
> mm/cma_debug.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/cma_debug.c b/mm/cma_debug.c
> index 2e7704955f4f..c3ffe253e055 100644
> --- a/mm/cma_debug.c
> +++ b/mm/cma_debug.c
> @@ -163,7 +163,7 @@ DEFINE_DEBUGFS_ATTRIBUTE(cma_alloc_fops, NULL, cma_alloc_write, "%llu\n");
> static void cma_debugfs_add_one(struct cma *cma, struct dentry *root_dentry)
> {
> struct dentry *tmp;
> - char name[16];
> + char name[CMA_MAX_NAME];
>
> scnprintf(name, sizeof(name), "cma-%s", cma->name);
Seems logical. But as CMA_MAX_NAME=64, this could result in alteration
of the output: less truncation of the original name.
Is it the case that the output is never >16 chars anyway? If so, we'll
be OK.
Hi, Andrew:
Is it the case that the output is never >16 chars anyway? If so, we'll be OK.
>> Yes. I verified on my device by giving cma.name length l< 16 and >16 both. Result is OK. I mean > 16 showed correctly with this patch.
>> without this patch, cma.name > 16, only showed 16 characters.
Best Regards
Kassey
This technical data may be subject to U.S. and international export, re-export, or transfer ("export") laws. Diversion contrary to U.S. and international law is strictly prohibited.
-----Original Message-----
From: Andrew Morton <[email protected]>
Sent: Wednesday, July 20, 2022 7:19 AM
To: Kassey Li (QUIC) <[email protected]>
Cc: [email protected]; Sasha Levin <[email protected]>; Joonsoo Kim <[email protected]>; Minchan Kim <[email protected]>
Subject: Re: [PATCH] mm/cma_debug.c: align the name buffer length as struct cma
On Tue, 19 Jul 2022 17:15:54 +0800 Kassey Li <[email protected]> wrote:
> Signed-off-by: Kassey Li <[email protected]>
> ---
> mm/cma_debug.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/cma_debug.c b/mm/cma_debug.c index
> 2e7704955f4f..c3ffe253e055 100644
> --- a/mm/cma_debug.c
> +++ b/mm/cma_debug.c
> @@ -163,7 +163,7 @@ DEFINE_DEBUGFS_ATTRIBUTE(cma_alloc_fops, NULL,
> cma_alloc_write, "%llu\n"); static void cma_debugfs_add_one(struct
> cma *cma, struct dentry *root_dentry) {
> struct dentry *tmp;
> - char name[16];
> + char name[CMA_MAX_NAME];
>
> scnprintf(name, sizeof(name), "cma-%s", cma->name);
Seems logical. But as CMA_MAX_NAME=64, this could result in alteration of the output: less truncation of the original name.
Is it the case that the output is never >16 chars anyway? If so, we'll be OK.
On Wed, 20 Jul 2022 10:45:33 +0000 "Kassey Li (QUIC)" <[email protected]> wrote:
> Hi, Andrew:
>
> Is it the case that the output is never >16 chars anyway? If so, we'll be OK.
> >> Yes. I verified on my device by giving cma.name length l< 16 and >16 both. Result is OK. I mean > 16 showed correctly with this patch.
> >> without this patch, cma.name > 16, only showed 16 characters.
>
Well that's my point. With this patch the output is changed and this
might break userspace code which expects the truncation.
That should be OK as there are no guarantees with debugfs interfaces.
I added this as the patch's changelog:
: Avoids truncating the debugfs output to 16 chars. Potentially alters
: the userspace output, but this is a debugfs interface and there are no
: stability guarantees.