From: Willy Tarreau <w@1wt.eu>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 3/6] tools/nolibc: properly align dirent buffer
Date: Sat, 19 Apr 2025 11:11:40 +0200 [thread overview]
Message-ID: <20250419091140.GC31874@1wt.eu> (raw)
In-Reply-To: <20250416-nolibc-ubsan-v1-3-c4704bb23da7@weissschuh.net>
On Wed, Apr 16, 2025 at 08:40:18PM +0200, Thomas Weißschuh wrote:
> As byte buffer is overlaid with a 'struct dirent64'.
> it has to satisfy the structs alignment requirements.
>
> Fixes: 665fa8dea90d ("tools/nolibc: add support for directory access")
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Oh good catch! I already faced crashes in other programs due to AVX
memcpy when doing similar casts without thinking about alignment.
> @@ -58,6 +58,7 @@ int closedir(DIR *dirp)
> static __attribute__((unused))
> int readdir_r(DIR *dirp, struct dirent *entry, struct dirent **result)
> {
> + __attribute__((aligned(__alignof__(struct linux_dirent64))))
> char buf[sizeof(struct linux_dirent64) + NAME_MAX + 1];
I tend to find it more readable when the attribute is on the same line as
the type on variables declaration, often at the end of the line, to keep
declarations alignes, even if that makes longer lines. If alignment concerns
come back often, we could maybe have __nolibc_align(<align>) and maybe even
__nolibc_align_as(<type>) to slightly shorten the lines. Just an idea.
In any case: Acked-by: Willy Tarreau <w@1wt.eu>
Willy
next prev parent reply other threads:[~2025-04-19 9:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-16 18:40 [PATCH 0/6] tools/nolibc: fix some undefined behaviour and enable UBSAN Thomas Weißschuh
2025-04-16 18:40 ` [PATCH 1/6] tools/nolibc: add __nolibc_has_feature() Thomas Weißschuh
2025-04-16 18:40 ` [PATCH 2/6] tools/nolibc: disable function sanitizer for _start_c() Thomas Weißschuh
2025-04-19 9:06 ` Willy Tarreau
2025-04-19 10:10 ` Thomas Weißschuh
2025-04-19 10:27 ` Willy Tarreau
2025-04-16 18:40 ` [PATCH 3/6] tools/nolibc: properly align dirent buffer Thomas Weißschuh
2025-04-19 9:11 ` Willy Tarreau [this message]
2025-04-19 10:11 ` Thomas Weißschuh
2025-04-16 18:40 ` [PATCH 4/6] tools/nolibc: fix integer overflow in i{64,}toa_r() and Thomas Weißschuh
2025-04-19 9:40 ` Willy Tarreau
2025-04-19 10:26 ` Thomas Weißschuh
2025-04-16 18:40 ` [PATCH 5/6] selftests/nolibc: disable ubsan for smash_stack() Thomas Weißschuh
2025-04-16 18:40 ` [PATCH 6/6] selftests/nolibc: enable UBSAN if available Thomas Weißschuh
2025-04-19 9:41 ` Willy Tarreau
2025-04-18 17:32 ` [PATCH 0/6] tools/nolibc: fix some undefined behaviour and enable UBSAN Paul E. McKenney
2025-04-18 21:20 ` Thomas Weißschuh
2025-04-18 21:29 ` Paul E. McKenney
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=20250419091140.GC31874@1wt.eu \
--to=w@1wt.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=paulmck@kernel.org \
--cc=shuah@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox