Re: [PATCH] string: instrument the word loads in sized_strscpy()

[Andrew Morton <akpm@linux-foundation.org>]

On Sat, 17 Oct 2026 22:05:03 -0700 Peter Collingbourne <peter@pcc.me.uk> wrote:

> > --- a/lib/string.c
> > +++ b/lib/string.c
> > @@ -19,6 +19,7 @@
> >  #include <linux/bug.h>
> >  #include <linux/ctype.h>
> >  #include <linux/errno.h>
> > +#include <linux/instrumented.h>
> >  #include <linux/limits.h>
> >  #include <linux/linkage.h>
> >  #include <linux/minmax.h>
> > @@ -132,6 +133,12 @@ ssize_t sized_strscpy(char *dest, const char *src, size_t count)
> >                 unsigned long c, data;
> >
> >  #ifdef CONFIG_DCACHE_WORD_ACCESS
> > +               /*
> > +                * Unlike read_word_at_a_time(), load_unaligned_zeropad() is
> > +                * not instrumented. Check the first byte, which must be
> > +                * readable, as read_word_at_a_time() does.
> > +                */
> > +               instrument_read(src + res, 1);
> >                 c = load_unaligned_zeropad(src+res);
> 
> It looks like at least some of the other callers of
> load_unaligned_zeropad() have the same problem. Would it be better to
> add the instrument_read() call to load_unaligned_zeropad()?

Well, with this setup (Kconfig-time and runtime), does our user
actually care about performance?  Can we simply use plain old C code in
these situations and not compromise the runtime checking?

I'm not sure why we have the assembly thing, really.  If the kernel is
spending significant amounts of time doing string copies then why the
heck?