[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75Vd_mJggRRLfziWUf0tgr3K125uVBNh9VdSo9LHVJz2r_w@mail.gmail.com>
Date: Wed, 26 Mar 2025 20:39:37 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Kees Cook <kees@...nel.org>, Andy Shevchenko <andy@...nel.org>,
Nick Desaulniers <nick.desaulniers+lkml@...il.com>, Bill Wendling <morbo@...gle.com>,
Justin Stitt <justinstitt@...gle.com>, Ard Biesheuvel <ardb@...nel.org>, linux-kernel@...r.kernel.org,
linux-hardening@...r.kernel.org, llvm@...ts.linux.dev, stable@...r.kernel.org
Subject: Re: [PATCH v2 2/2] lib/string.c: Add wcslen()
On Wed, Mar 26, 2025 at 7:19 PM Nathan Chancellor <nathan@...nel.org> wrote:
>
> A recent optimization change in LLVM [1] aims to transform certain loop
> idioms into calls to strlen() or wcslen(). This change transforms the
> first while loop in UniStrcat() into a call to wcslen(), breaking the
> build when UniStrcat() gets inlined into alloc_path_with_tree_prefix():
>
> ld.lld: error: undefined symbol: wcslen
> >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54)
> >>> vmlinux.o:(alloc_path_with_tree_prefix)
> >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54)
> >>> vmlinux.o:(alloc_path_with_tree_prefix)
>
> The kernel does not build with '-ffreestanding' (which would avoid this
> transformation) because it does want libcall optimizations in general
> and turning on '-ffreestanding' disables the majority of them. While
> '-fno-builtin-wcslen' would be more targeted at the problem, it does not
> work with LTO.
>
> Add a basic wcslen() to avoid this linkage failure. While no
> architecture or FORTIFY_SOURCE overrides this, add it to string.c
> instead of string_helpers.c so that it is built with '-ffreestanding',
> otherwise the compiler might transform it into a call to itself.
...
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -7,6 +7,7 @@
> #include <linux/cleanup.h> /* for DEFINE_FREE() */
> #include <linux/compiler.h> /* for inline */
> #include <linux/types.h> /* for size_t */
> +#include <linux/nls_types.h> /* for wchar_t */
I know it's not ordered, but can we at least not make it worse, i.e.
squeeze this to be after the compiler.h? Or even somewhere after below
the err*.h? Whatever gives a better (sparsely) ordered overall
result...
> #include <linux/stddef.h> /* for NULL */
> #include <linux/err.h> /* for ERR_PTR() */
...
> #ifndef __HAVE_ARCH_STRNLEN
> extern __kernel_size_t strnlen(const char *,__kernel_size_t);
> #endif
> +extern __kernel_size_t wcslen(const wchar_t *s);
I'm wondering why we still continue putting this 'extern' keyword.
Yes, I see that the rest is like this, but for new code do we really
need it?
> #ifndef __HAVE_ARCH_STRPBRK
> extern char * strpbrk(const char *,const char *);
> #endif
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists