On Mon, Jan 27, 2025 at 05:27:08PM -0800, Linus Torvalds wrote:
> On Mon, 27 Jan 2025 at 17:21, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > Umm... On some architectures it does, but mostly that's the ones
> > where unaligned word loads are costly. Which target do you have
> > in mind?
>
> I was more thinking that we could just make the fallback case be a 'memcmp()'.
>
> It's not like this particular place matters - as you say, that
> byte-at-a-time code is only used on architectures that don't enable
> the dcache word-at-a-time code (that requires the special "do loads
> that can fault" zeropad helper), but we've had some other places where
> we'd worry about the string length.
>
> Look at d_path() for another example. That copy_from_kernel_nofault()
> in prepend_copy()...
Hmm... So something like
/*
* Returns a pointer to name and a length; length might be
* inaccurate in case of race with dentry renaming, but
* it will not exceed the distance from returned pointer
* to the end of containing object.
* Caller MUST hold rcu_read_lock().
* Caller MUST NOT expect the contents of name to remain
* stable - it can change at any time.
*/
const char *__d_name_rcu(struct dentry *dentry, int *p)
{
const char *name = smp_load_acquire(&dentry->d_name.name);
if (unlikely(name != &dentry->d_shortname.string))
*p = container_of(name, struct external_name, name)->len;
else if (unlikely((*p = dentry->d_name.name) >= DNAME_INLINE_LEN)
*p = DNAME_INLINE_LEN - 1;
return name;
}
with very limited accessibility (basically, dcache.c and d_path.c)
prepend_name() might be able to use that...
