All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] [PATCH] syscalls/statvfs01: Correcly zero terminate the strings
@ 2023-01-18 13:36 Cyril Hrubis
  2023-01-18 16:40 ` Petr Vorel
  2023-01-18 17:01 ` Martin Doucha
  0 siblings, 2 replies; 6+ messages in thread
From: Cyril Hrubis @ 2023-01-18 13:36 UTC (permalink / raw)
  To: ltp; +Cc: Richard Palethorpe

Fixes random failures caused by the fact that the stack is not
guaranteed to be zeroed.

Fixes: e305ac4a305f ("statvfs01: Convert to new LTP API")
Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
CC: Petr Vorel <pvorel@suse.cz>
CC: Richard Palethorpe <rpalethorpe@suse.com>
CC: Avinesh Kumar <akumar@suse.de>
---
 testcases/kernel/syscalls/statvfs/statvfs01.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/testcases/kernel/syscalls/statvfs/statvfs01.c b/testcases/kernel/syscalls/statvfs/statvfs01.c
index dd14d6a0e..f17dc4cfa 100644
--- a/testcases/kernel/syscalls/statvfs/statvfs01.c
+++ b/testcases/kernel/syscalls/statvfs/statvfs01.c
@@ -38,6 +38,9 @@ static void run(void)
 	memset(valid_fname, 'a', valid_len);
 	memset(toolong_fname, 'b', valid_len + 1);
 
+	valid_fname[valid_len] = 0;
+	toolong_fname[valid_len+1] = 0;
+
 	TST_EXP_FD(creat(valid_fname, 0444));
 	SAFE_CLOSE(TST_RET);
 
-- 
2.38.2


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [LTP] [PATCH] syscalls/statvfs01: Correcly zero terminate the strings
  2023-01-18 13:36 [LTP] [PATCH] syscalls/statvfs01: Correcly zero terminate the strings Cyril Hrubis
@ 2023-01-18 16:40 ` Petr Vorel
  2023-01-18 17:01 ` Martin Doucha
  1 sibling, 0 replies; 6+ messages in thread
From: Petr Vorel @ 2023-01-18 16:40 UTC (permalink / raw)
  To: Cyril Hrubis; +Cc: Richard Palethorpe, ltp

Hi Cyril,

I'm sorry not catching these, thanks for fixing.

Reviewed-by: Petr Vorel <pvorel@suse.cz>

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LTP] [PATCH] syscalls/statvfs01: Correcly zero terminate the strings
  2023-01-18 13:36 [LTP] [PATCH] syscalls/statvfs01: Correcly zero terminate the strings Cyril Hrubis
  2023-01-18 16:40 ` Petr Vorel
@ 2023-01-18 17:01 ` Martin Doucha
  2023-01-18 21:40   ` Petr Vorel
  2023-01-19 14:41   ` Cyril Hrubis
  1 sibling, 2 replies; 6+ messages in thread
From: Martin Doucha @ 2023-01-18 17:01 UTC (permalink / raw)
  To: Cyril Hrubis, ltp; +Cc: Richard Palethorpe

Hi,

On 18. 01. 23 14:36, Cyril Hrubis wrote:
> Fixes random failures caused by the fact that the stack is not
> guaranteed to be zeroed.
> 
> Fixes: e305ac4a305f ("statvfs01: Convert to new LTP API")
> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> CC: Petr Vorel <pvorel@suse.cz>
> CC: Richard Palethorpe <rpalethorpe@suse.com>
> CC: Avinesh Kumar <akumar@suse.de>
> ---
>   testcases/kernel/syscalls/statvfs/statvfs01.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/testcases/kernel/syscalls/statvfs/statvfs01.c b/testcases/kernel/syscalls/statvfs/statvfs01.c
> index dd14d6a0e..f17dc4cfa 100644
> --- a/testcases/kernel/syscalls/statvfs/statvfs01.c
> +++ b/testcases/kernel/syscalls/statvfs/statvfs01.c
> @@ -38,6 +38,9 @@ static void run(void)
>   	memset(valid_fname, 'a', valid_len);
>   	memset(toolong_fname, 'b', valid_len + 1);
>   
> +	valid_fname[valid_len] = 0;
> +	toolong_fname[valid_len+1] = 0;

Is there a possibility that valid_len could be equal to PATH_MAX-1? I 
think toolong_fname[] size should be bumped to at least PATH_MAX+1.

> +
>   	TST_EXP_FD(creat(valid_fname, 0444));
>   	SAFE_CLOSE(TST_RET);
>   

-- 
Martin Doucha   mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LTP] [PATCH] syscalls/statvfs01: Correcly zero terminate the strings
  2023-01-18 17:01 ` Martin Doucha
@ 2023-01-18 21:40   ` Petr Vorel
  2023-01-19 14:41   ` Cyril Hrubis
  1 sibling, 0 replies; 6+ messages in thread
From: Petr Vorel @ 2023-01-18 21:40 UTC (permalink / raw)
  To: Martin Doucha; +Cc: ltp, Richard Palethorpe

> Hi,

> On 18. 01. 23 14:36, Cyril Hrubis wrote:
> > Fixes random failures caused by the fact that the stack is not
> > guaranteed to be zeroed.

> > Fixes: e305ac4a305f ("statvfs01: Convert to new LTP API")
> > Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> > CC: Petr Vorel <pvorel@suse.cz>
> > CC: Richard Palethorpe <rpalethorpe@suse.com>
> > CC: Avinesh Kumar <akumar@suse.de>
> > ---
> >   testcases/kernel/syscalls/statvfs/statvfs01.c | 3 +++
> >   1 file changed, 3 insertions(+)

> > diff --git a/testcases/kernel/syscalls/statvfs/statvfs01.c b/testcases/kernel/syscalls/statvfs/statvfs01.c
> > index dd14d6a0e..f17dc4cfa 100644
> > --- a/testcases/kernel/syscalls/statvfs/statvfs01.c
> > +++ b/testcases/kernel/syscalls/statvfs/statvfs01.c
> > @@ -38,6 +38,9 @@ static void run(void)
> >   	memset(valid_fname, 'a', valid_len);
> >   	memset(toolong_fname, 'b', valid_len + 1);
> > +	valid_fname[valid_len] = 0;
> > +	toolong_fname[valid_len+1] = 0;

> Is there a possibility that valid_len could be equal to PATH_MAX-1? I think

PATH_MAX is 4096. statvfs.f_namemax is mostly 255 (only for vfat and exfat is
1530, but that's for multibyte names, the "real" length, when counting
characters is also 255).

> toolong_fname[] size should be bumped to at least PATH_MAX+1.
statvfs01.c:43:22: warning: array subscript 4097 is above array bounds of ‘char[4096]’ [-Warray-bounds]
=> PATH_MAX-1 is the maximum (array size is PATH_MAX).

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LTP] [PATCH] syscalls/statvfs01: Correcly zero terminate the strings
  2023-01-18 17:01 ` Martin Doucha
  2023-01-18 21:40   ` Petr Vorel
@ 2023-01-19 14:41   ` Cyril Hrubis
  2023-01-19 14:56     ` Martin Doucha
  1 sibling, 1 reply; 6+ messages in thread
From: Cyril Hrubis @ 2023-01-19 14:41 UTC (permalink / raw)
  To: Martin Doucha; +Cc: Richard Palethorpe, ltp

Hi!
> >   	memset(valid_fname, 'a', valid_len);
> >   	memset(toolong_fname, 'b', valid_len + 1);
> >   
> > +	valid_fname[valid_len] = 0;
> > +	toolong_fname[valid_len+1] = 0;
> 
> Is there a possibility that valid_len could be equal to PATH_MAX-1?

I do not think so, POSIX explicitly says that PATH_MAX should include
space for terminating null character.

Btw there is NAME_MAX constant that is defined to 256 which is the
usuall maximal lenght + 1.

> I  think toolong_fname[] size should be bumped to at least PATH_MAX+1.

Well we can do that (in a separate patch) to be extra sure, but even
then the PATH_MAX seems to be at least order of magnitude larger than
NAME_MAX.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LTP] [PATCH] syscalls/statvfs01: Correcly zero terminate the strings
  2023-01-19 14:41   ` Cyril Hrubis
@ 2023-01-19 14:56     ` Martin Doucha
  0 siblings, 0 replies; 6+ messages in thread
From: Martin Doucha @ 2023-01-19 14:56 UTC (permalink / raw)
  To: Cyril Hrubis; +Cc: Richard Palethorpe, ltp

On 19. 01. 23 15:41, Cyril Hrubis wrote:
> Hi!
>>>    	memset(valid_fname, 'a', valid_len);
>>>    	memset(toolong_fname, 'b', valid_len + 1);
>>>    
>>> +	valid_fname[valid_len] = 0;
>>> +	toolong_fname[valid_len+1] = 0;
>>
>> Is there a possibility that valid_len could be equal to PATH_MAX-1?
> 
> I do not think so, POSIX explicitly says that PATH_MAX should include
> space for terminating null character.

That's still true if valid_len == PATH_MAX-1. But we write valid_len+2 
bytes into toolong_fname.

But if always f_namemax <<< PATH_MAX, then we don't need to do anything.

-- 
Martin Doucha   mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-01-19 14:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-18 13:36 [LTP] [PATCH] syscalls/statvfs01: Correcly zero terminate the strings Cyril Hrubis
2023-01-18 16:40 ` Petr Vorel
2023-01-18 17:01 ` Martin Doucha
2023-01-18 21:40   ` Petr Vorel
2023-01-19 14:41   ` Cyril Hrubis
2023-01-19 14:56     ` Martin Doucha

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.