2021-12-15 19:21:46

by Miko Larsson

[permalink] [raw]
Subject: [PATCH 0/2] zram: zram_drv: Fix some formatting problems

Hi,

This small patch set fixes some superficial formatting problems in
zram_drv that were reported by checkpatch, namely that it missed SPDX
license identifiers and that it used strlcopy instead of strscpy.

Miko Larsson (2):
zram: zram_drv: add SPDX license identifiers
zram: zram_drv: replace strlcpy with strscpy

drivers/block/zram/zram_drv.c | 8 +++++---
drivers/block/zram/zram_drv.h | 2 ++
2 files changed, 7 insertions(+), 3 deletions(-)

--
2.34.1



2021-12-15 19:21:47

by Miko Larsson

[permalink] [raw]
Subject: [PATCH 2/2] zram: zram_drv: replace strlcpy with strscpy

strlcpy shouldn't be used; strscpy should be used instead.

Signed-off-by: Miko Larsson <[email protected]>
---
drivers/block/zram/zram_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 464ef53adcbc..b1774d04a6ea 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -500,7 +500,7 @@ static ssize_t backing_dev_store(struct device *dev,
goto out;
}

- strlcpy(file_name, buf, PATH_MAX);
+ strscpy(file_name, buf, PATH_MAX);
/* ignore trailing newline */
sz = strlen(file_name);
if (sz > 0 && file_name[sz - 1] == '\n')
@@ -1034,7 +1034,7 @@ static ssize_t comp_algorithm_store(struct device *dev,
char compressor[ARRAY_SIZE(zram->compressor)];
size_t sz;

- strlcpy(compressor, buf, sizeof(compressor));
+ strscpy(compressor, buf, sizeof(compressor));
/* ignore trailing newline */
sz = strlen(compressor);
if (sz > 0 && compressor[sz - 1] == '\n')
@@ -1988,7 +1988,7 @@ static int zram_add(void)
if (ret)
goto out_cleanup_disk;

- strlcpy(zram->compressor, default_compressor, sizeof(zram->compressor));
+ strscpy(zram->compressor, default_compressor, sizeof(zram->compressor));

zram_debugfs_register(zram);
pr_info("Added device: %s\n", zram->disk->disk_name);
--
2.34.1


2021-12-16 10:14:51

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 2/2] zram: zram_drv: replace strlcpy with strscpy

On Wed, Dec 15, 2021 at 08:21:28PM +0100, Miko Larsson wrote:
> strlcpy shouldn't be used; strscpy should be used instead.

I think the proper API to use here would be kmemdup_nul.

2021-12-16 15:00:34

by Miko Larsson

[permalink] [raw]
Subject: Re: [PATCH 2/2] zram: zram_drv: replace strlcpy with strscpy

On Thu, 16 Dec 2021 02:14:44 -0800
Christoph Hellwig <[email protected]> wrote:

> On Wed, Dec 15, 2021 at 08:21:28PM +0100, Miko Larsson wrote:
> > strlcpy shouldn't be used; strscpy should be used instead.
>
> I think the proper API to use here would be kmemdup_nul.

Thanks for the heads-up! That only seems to apply to the assignment of
'file_name'. The usage of strscpy seems to be correct in the other two
cases, though (since they're char arrays.) I suspect I might be wrong
though, since my knowledge of C is shabby at best.

2021-12-16 17:52:10

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 2/2] zram: zram_drv: replace strlcpy with strscpy

On Thu, Dec 16, 2021 at 04:00:21PM +0100, Miko Larsson wrote:
> Thanks for the heads-up! That only seems to apply to the assignment of
> 'file_name'. The usage of strscpy seems to be correct in the other two
> cases, though (since they're char arrays.) I suspect I might be wrong
> though, since my knowledge of C is shabby at best.

The second one also sounds like a case for memdup_nul. That adds a
memory allocation, but it keeps all the checking nicely encapsulated,
and the last one should be fine with a plain old mempcy.

2021-12-16 17:52:47

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 2/2] zram: zram_drv: replace strlcpy with strscpy

On Thu, Dec 16, 2021 at 09:52:01AM -0800, Christoph Hellwig wrote:
> On Thu, Dec 16, 2021 at 04:00:21PM +0100, Miko Larsson wrote:
> > Thanks for the heads-up! That only seems to apply to the assignment of
> > 'file_name'. The usage of strscpy seems to be correct in the other two
> > cases, though (since they're char arrays.) I suspect I might be wrong
> > though, since my knowledge of C is shabby at best.
>
> The second one also sounds like a case for memdup_nul. That adds a
> memory allocation, but it keeps all the checking nicely encapsulated,
> and the last one should be fine with a plain old mempcy.

sorry, s/memcpy/strcpy/