[PATCH v1 1/1] string: Export strnchrnul()

[PATCH v1 1/1] string: Export strnchrnul()

[Andy Shevchenko]

Export strnchrnul() for users that may be compiled as modules.

Reported-by: Armin Wolf <W_Armin@gmx.de>
Closes: https://lore.kernel.org/r/1969fb5a-38ef-4b4b-9d2f-cb9a4348b968@gmx.de
Fixes: 0bee0cece2a6 ("lib/string: add strnchrnul()")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---

Assumed to go via PDx86 where the first (wow!) module user wants to use it.

 lib/string.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/string.c b/lib/string.c
index a3778d5aab4a..cc8982a93afc 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -352,6 +352,7 @@ char *strnchrnul(const char *s, size_t count, int c)
 		s++;
 	return (char *)s;
 }
+EXPORT_SYMBOL(strnchrnul);
 
 #ifndef __HAVE_ARCH_STRRCHR
 /**
-- 
2.50.1

Re: [PATCH v1 1/1] string: Export strnchrnul()

[Andy Shevchenko]

On Tue, Nov 10, 2026 at 05:41:50PM +0100, Andy Shevchenko wrote:
> Export strnchrnul() for users that may be compiled as modules.
> 
> Reported-by: Armin Wolf <W_Armin@gmx.de>
> Closes: https://lore.kernel.org/r/1969fb5a-38ef-4b4b-9d2f-cb9a4348b968@gmx.de
> Fixes: 0bee0cece2a6 ("lib/string: add strnchrnul()")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> 
> Assumed to go via PDx86 where the first (wow!) module user wants to use it.

Actually with the given Fixes tag it may go usual way to next -rcX.
So, whatever appropriate the respective maintainers think...


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/1] string: Export strnchrnul()

[Armin Wolf]

Am 10.11.26 um 17:41 schrieb Andy Shevchenko:
> Export strnchrnul() for users that may be compiled as modules.

Reviewed-by: Armin Wolf <W_Armin@gmx.de>

> Reported-by: Armin Wolf <W_Armin@gmx.de>
> Closes: https://lore.kernel.org/r/1969fb5a-38ef-4b4b-9d2f-cb9a4348b968@gmx.de
> Fixes: 0bee0cece2a6 ("lib/string: add strnchrnul()")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> 
> Assumed to go via PDx86 where the first (wow!) module user wants to use it.
> 
>   lib/string.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/lib/string.c b/lib/string.c
> index a3778d5aab4a..cc8982a93afc 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -352,6 +352,7 @@ char *strnchrnul(const char *s, size_t count, int c)
>   		s++;
>   	return (char *)s;
>   }
> +EXPORT_SYMBOL(strnchrnul);
>   
>   #ifndef __HAVE_ARCH_STRRCHR
>   /**

Re: [PATCH v1 1/1] string: Export strnchrnul()

[Yury Norov]

On Tue, Nov 10, 2026 at 05:41:50PM +0100, Andy Shevchenko wrote:
> Export strnchrnul() for users that may be compiled as modules.
> 
> Reported-by: Armin Wolf <W_Armin@gmx.de>
> Closes: https://lore.kernel.org/r/1969fb5a-38ef-4b4b-9d2f-cb9a4348b968@gmx.de
> Fixes: 0bee0cece2a6 ("lib/string: add strnchrnul()")

Not sure that exporting a symbol is actually a fix. It rather looks
like a normal development. Also, I'd like to have this patch attached
to the PDx86 or whatever series that uses it.

Their implementation may change, so this would become the exported
symbols space bloat.

Thanks,
Yury

> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> 
> Assumed to go via PDx86 where the first (wow!) module user wants to use it.
> 
>  lib/string.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/string.c b/lib/string.c
> index a3778d5aab4a..cc8982a93afc 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -352,6 +352,7 @@ char *strnchrnul(const char *s, size_t count, int c)
>  		s++;
>  	return (char *)s;
>  }
> +EXPORT_SYMBOL(strnchrnul);
>  
>  #ifndef __HAVE_ARCH_STRRCHR
>  /**
> -- 
> 2.50.1
> 

Re: [PATCH v1 1/1] string: Export strnchrnul()

[Ilpo Järvinen]

On Tue, 10 Nov 2026, Andy Shevchenko wrote:

> Export strnchrnul() for users that may be compiled as modules.
> 
> Reported-by: Armin Wolf <W_Armin@gmx.de>
> Closes: https://lore.kernel.org/r/1969fb5a-38ef-4b4b-9d2f-cb9a4348b968@gmx.de
> Fixes: 0bee0cece2a6 ("lib/string: add strnchrnul()")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> 
> Assumed to go via PDx86 where the first (wow!) module user wants to use it.

Thanks guys,

I'm so surprised by this, sashiko did warn about this so I even checked 
myself and saw an export after the closing brace so thought sashiko was 
just wrong... Maybe I was looking that the strrchr's export, can't think 
of anything else to explain it.

>  lib/string.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/string.c b/lib/string.c
> index a3778d5aab4a..cc8982a93afc 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -352,6 +352,7 @@ char *strnchrnul(const char *s, size_t count, int c)
>  		s++;
>  	return (char *)s;
>  }
> +EXPORT_SYMBOL(strnchrnul);
>  
>  #ifndef __HAVE_ARCH_STRRCHR
>  /**
> 

-- 
 i.

Re: [PATCH v1 1/1] string: Export strnchrnul()

[Ilpo Järvinen]

On Tue, 10 Nov 2026, Yury Norov wrote:

> On Tue, Nov 10, 2026 at 05:41:50PM +0100, Andy Shevchenko wrote:
> > Export strnchrnul() for users that may be compiled as modules.
> > 
> > Reported-by: Armin Wolf <W_Armin@gmx.de>
> > Closes: https://lore.kernel.org/r/1969fb5a-38ef-4b4b-9d2f-cb9a4348b968@gmx.de
> > Fixes: 0bee0cece2a6 ("lib/string: add strnchrnul()")
> 
> Not sure that exporting a symbol is actually a fix. It rather looks
> like a normal development. Also, I'd like to have this patch attached
> to the PDx86 or whatever series that uses it.

I did put it now before the change that broke because of the missing 
export.

I dropped Closes and Fixes tags as the issue should be non-problem after 
the history rewrite.

-- 
 i.

> Their implementation may change, so this would become the exported
> symbols space bloat.
> 
> Thanks,
> Yury
> 
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> > 
> > Assumed to go via PDx86 where the first (wow!) module user wants to use it.
> > 
> >  lib/string.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/lib/string.c b/lib/string.c
> > index a3778d5aab4a..cc8982a93afc 100644
> > --- a/lib/string.c
> > +++ b/lib/string.c
> > @@ -352,6 +352,7 @@ char *strnchrnul(const char *s, size_t count, int c)
> >  		s++;
> >  	return (char *)s;
> >  }
> > +EXPORT_SYMBOL(strnchrnul);
> >  
> >  #ifndef __HAVE_ARCH_STRRCHR
> >  /**
> > -- 
> > 2.50.1
> > 
> 

-- 
 i.

Re: [PATCH v1 1/1] string: Export strnchrnul()

[Yury Norov]

On Tue, Nov 10, 2026 at 1:39 PM Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Tue, 10 Nov 2026, Yury Norov wrote:
>
> > On Tue, Nov 10, 2026 at 05:41:50PM +0100, Andy Shevchenko wrote:
> > > Export strnchrnul() for users that may be compiled as modules.
> > >
> > > Reported-by: Armin Wolf <W_Armin@gmx.de>
> > > Closes: https://lore.kernel.org/r/1969fb5a-38ef-4b4b-9d2f-cb9a4348b968@gmx.de
> > > Fixes: 0bee0cece2a6 ("lib/string: add strnchrnul()")
> >
> > Not sure that exporting a symbol is actually a fix. It rather looks
> > like a normal development. Also, I'd like to have this patch attached
> > to the PDx86 or whatever series that uses it.
>
> I did put it now before the change that broke because of the missing
> export.
>
> I dropped Closes and Fixes tags as the issue should be non-problem after
> the history rewrite.

OK, then

Reviewed-by: Yury Norov <ynorov@nvidia.com>

Re: [PATCH v1 1/1] string: Export strnchrnul()

[Andy Shevchenko]

On Tue, Nov 10, 2026 at 08:29:58PM +0200, Ilpo Järvinen wrote:
> On Tue, 10 Nov 2026, Andy Shevchenko wrote:
> 
> > Export strnchrnul() for users that may be compiled as modules.
> > 
> > Reported-by: Armin Wolf <W_Armin@gmx.de>
> > Closes: https://lore.kernel.org/r/1969fb5a-38ef-4b4b-9d2f-cb9a4348b968@gmx.de
> > Fixes: 0bee0cece2a6 ("lib/string: add strnchrnul()")
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> > 
> > Assumed to go via PDx86 where the first (wow!) module user wants to use it.
> 
> Thanks guys,
> 
> I'm so surprised by this, sashiko did warn about this so I even checked 
> myself and saw an export after the closing brace so thought sashiko was 
> just wrong... Maybe I was looking that the strrchr's export, can't think 
> of anything else to explain it.

The strchrnul is exported, I believe you missed 'n' which may explain the
course of what happened. Compare:

 EXPORT_SYMBOL(strchrnul);
 EXPORT_SYMBOL(strnchrnul);

If you don't stare on this, you won't notice the difference at a glance.
(I caught myself on the same, but it was after this report, so I spend
 a few more seconds to get it.)

-- 
With Best Regards,
Andy Shevchenko