On Sat, 17 Oct 2026 22:05:03 -0700 Peter Collingbourne <[email protected]> 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?
