[BUG] procfs: "cd /proc/n" succeeds

[pipcet]

Description / Steps to reproduce the issue

The procfs code behaves strangely when dealing with a path which is a prefix of a valid procfs entry: changing directory to such a prefix works rather than failing, and the apparent entries correspond to the remaining path, with one byte omitted.

In this configuration, /proc/net exists, but /proc/n doesn't:

nsh> cd /proc/n
nsh> ls
/proc/n:
 t
 t/
nsh> 

I would have expected behavior analogous to:

nsh> cd /proc/x
nsh: cd: chdir failed: 2
nsh> 

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

6.6.21

NuttX Version

master

Issue Architecture

[Arch: xtensa]

Issue Area

[Area: File System]

Host information

No response

Verification

• I have verified before submitting the report.

[acassis]

@pipcet really nice finding! This finding confirms how testing is very important!

Confirmed using sim tcpblaster, all directories inside /proc behaves same way:

NuttShell (NSH) NuttX-12.9.0
nsh> ls /proc
/proc:
 0/
 1/
 2/
 3/
 4/
 cpuinfo
 fs/
 iobinfo
 memdump
 meminfo
 net/
 self/
 tcbinfo
 uptime
 version
nsh> cd /proc/f
nsh> ls
/proc/f:
 /
 /
 /
nsh> cd ../n
nsh> ls
/proc/n:
 t
 t/
nsh> cd ../s
nsh> ls
/proc/s:
 lf
 lf/
nsh> 

@xiaoxiang781216

[acassis]

I think this issue always existed and nobody found it before @pipcet (kudos buddy!)

$ ./nuttx 
TAPDEV: ioctl failed: 1

NuttShell (NSH) NuttX-9.0.0
nsh> ls /proc
/proc:
 0/
 1/
 2/
 3/
 meminfo
 iobinfo
 fs/
 net/
 self/
 uptime
 version
nsh> cd /proc/s
nsh> ls
/proc/s:
 lf
 lf/
nsh>

[pipcet]

@acassis Thanks. This find was literally due to a typo,

pipcet@6902de9 is a possible, quite minimal fix for the issue, but I'm not totally sure that the other instances of strncmp in fs_procfs.c are all okay.

[acassis]

@pipcet I think that could be a possible workaround. But I don't know if it will work when we add wildcard to nuttx, i.e. "ls /proc/n*" or "ls /proc/s*". I think in this case this fix will not work, right?

[pipcet]

@acassis Hmm. IIUC, the usual way of implementing wildcards on POSIX-like file systems does not involve making the file system itself recognize prefixes; instead, glob calls readdir and goes through all entries to attempt to match them against the provided pattern.

So I don't think globbing's a problem, but there's a second kind of wildcard: fs_procfs.c itself recognizes wildcards such as pressure/** to forward operations to another file system. All but one of these patterns use /**, which should be fine, but there's this:

#if defined(CONFIG_FS_SMARTFS) && !defined(CONFIG_FS_PROCFS_EXCLUDE_SMARTFS)
  { "fs/smartfs**", &g_smartfs_procfs_operations,  PROCFS_UNKOWN_TYPE },
#endif

I missed that, and I'm not sure whether my patch handles it correctly. It seems like /proc/smartfsX and /proc/smartfs/X are both recognized by the code (where X is i_name), but I don't quite understand how ls /proc/fs/smartfs* would list /proc/fs/smartfsX, yet.

[acassis]

Hi @pipcet interesting, I didn't know about it. How to forward operations to another file system? I think we don't have any documentation about it.

@xiaoxiang781216 @raiden00pl @pkarashchenko @lupyuen any suggestion?

[acassis]

@pipcet since nobody commented, please submit your PR with this proposed fix. It is better to have a fix that works with current code than keeping the BUG