On Tue, 2025-03-18 at 22:32 +0100, Ard Biesheuvel wrote: > Hi James, > > Thanks for persisting with this. Heh, well, it is starting to feel a bit like the swamp I can't get out of ... > On Tue, 18 Mar 2025 at 20:44, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > No functional change. Preparatory to using the internal function > > to iterate a directory with just a dentry not a file. > > > > Signed-off-by: James Bottomley > > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > > --- > > fs/libfs.c | 41 +++++++++++++++++++++++++++++------------ > > 1 file changed, 29 insertions(+), 12 deletions(-) > > > > diff --git a/fs/libfs.c b/fs/libfs.c > > index 8444f5cc4064..816bfe6c0430 100644 > > --- a/fs/libfs.c > > +++ b/fs/libfs.c > > @@ -189,28 +189,21 @@ EXPORT_SYMBOL(dcache_dir_lseek); > > * for ramfs-type trees they can't go away without unlink() or > > rmdir(), > > * both impossible due to the lock on directory. > > */ > > - > > -int dcache_readdir(struct file *file, struct dir_context *ctx) > > +static void internal_readdir(struct dentry *dentry, struct dentry > > *cursor, > > It might make sense to make this __always_inline, so that the > callback argument is guaranteed to become a compile time constant > when the caller is dcache_readdir(). Otherwise, the indirect call > overhead might impact its performance. I was hoping the compiler would pick that up ... especially as it's a tail call, but I can add it if necessary. Regards, James
