From: Cyril Hrubis <chrubis@suse.cz>
To: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 3/3] Provide a PATH_MAX-long buffer when expecting ENAMETOOLONG
Date: Tue, 24 Oct 2023 11:36:39 +0200 [thread overview]
Message-ID: <ZTeQJ95GncF5yg8F@yuki> (raw)
In-Reply-To: <e6cc15ff-cb44-4805-cba5-9f5340410746@arm.com>
Hi!
> > Sigh, I meant 2. I guess that we would have to loop over filesystems
> > (easily done with .all_filesystems = 1) and pass very long filename. Or
> > do we have such test already?
> >
> > Looking at our tests, the rename10.c is actually one of two tests that
> > sets .all_fileystems and checks for ENAMETOOLONG. Looking at the
> > filesystem limits, all seems to have limits that are <= 255 characters,
> > the only problem is a definition of character. For utf8 character 255
> > characters are around 1021 (including nul terminator). So I suppose that
> > if we pass another buffer that is PATH_MAX in length and has PATH_MAX-1
> > characters we should consistenly hit 2. Or do I miss something?
>
> This is a good point, I didn't think about it this way. Your idea seems
> sensible. With this patch we always hit 1. as we specify a string that
> is longer than PATH_MAX. We could instead hit 2. without out-of-bound
> access by specifying a string that is at most PATH_MAX in length
> (including the null terminator), and at least the filesystem character
> limit. Maybe something like the diff below (just tested it, that works
> fine).
Can we actually have two long paths in the test and test both? That
should have the best test coverage.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2023-10-24 9:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 13:56 [LTP] [PATCH 0/3] Various fixes for out-of-bound uaccess Kevin Brodsky
2023-10-23 13:56 ` [LTP] [PATCH 1/3] syscalls/{, f}setxattr: Fix passing of value pointer Kevin Brodsky
2023-10-23 13:56 ` [LTP] [PATCH 2/3] syscalls/msgctl06: Pass an appropriate struct to msgsnd() Kevin Brodsky
2023-10-23 13:56 ` [LTP] [PATCH 3/3] Provide a PATH_MAX-long buffer when expecting ENAMETOOLONG Kevin Brodsky
2023-10-23 14:40 ` Cyril Hrubis
2023-10-23 14:50 ` Kevin Brodsky
2023-10-23 15:06 ` Cyril Hrubis
2023-10-24 9:07 ` Kevin Brodsky
2023-10-24 9:36 ` Cyril Hrubis [this message]
2023-10-24 10:36 ` Kevin Brodsky
2023-10-23 14:39 ` [LTP] [PATCH 0/3] Various fixes for out-of-bound uaccess Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTeQJ95GncF5yg8F@yuki \
--to=chrubis@suse.cz \
--cc=kevin.brodsky@arm.com \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.