About a probable 32 bit ino_t bottleneck in cd9660_fhtovp()

["Thomas Schmitt" <scdbackup%gmx.net@localhost>]

Hi,

i riddle under which circumstances function cd9660_fhtovp() is
called (e.g. via VFS_FHTOVP).

Because, if it gets called for a file from my test ISO, then
it should fail due to a 32-bit bottleneck in the cd9660-specific
data of struct fid (i.e. in struct ifid).

I wanted to prepare a PR, but fail to get this function called
so that the problem would show up.

No problem - no report, one could say.
But my findings are suspicious. So i ask here for a use case
of VFS_FHTOVP.

I just read "man 9 vfsops" which says
     int (*vfs_fhtovp)()        VFS_FHTOVP        NFS file handle to vnode
                                                  lookup
     int (*vfs_vptofh)()        VFS_VPTOFH        Vnode to NFS file handle
                                                  lookup

Is there a tutorial "Localhost NFS for Dummies" ?

My PR sketch:
-----------------------------------------------------------------
Probable 32 bit ino_t bottleneck in interface of cd9660 to vfsops
-----------------------------------------------------------------

During my assessment of the relation between struct iso_node and
ISO 9660 File Sections, i came to the definition of the cd9660
version of vsops struct fid.
struct ifid is declared in cd9660_vfsops.c with comment
"File handle to vnode":

  struct ifid {
        ushort  ifid_len;
        ushort  ifid_pad;
        int     ifid_ino;
        long    ifid_start;
  };

Function cd9660_vptofh() copies this struct over a struct fid
which is provided by the caller.
Before this copying ifid_ino gets filled with the lower 32 bit of
an ino_t value (ip is a struct iso_node, ip->i_number is ino_t):

        ifh.ifid_ino = ip->i_number;

The higher bits are thrown away, obviously.

Function cd9660_fhtovp() copies such bytes back from struct fid
into a local struct ifid and uses .ifid_ino with

        if ((error = VFS_VGET(mp, ifh.ifid_ino, &nvp)) != 0) {

VFS_VGET to my assessment is actually function cd9660_vget_internal().
It uses cd9660_ihashget() to look up a vnode.

I inserted a printf() in cd9660_ihashget(), mounted my test ISO,
and got lots of more-than-32-bit numbers into /var/log/messages.
  May 10 18:55:39 netbsd /netbsd: cd9660_ihashget: inum = 4329412608

I moved the printf() to cd9660_fhtovp() and cannot provoke any
such messages in /var/log/messages.

-----------------------------------------------------------------

Test ISO is

    http://scdbackup.webframe.org/large.iso.bz2
 
4470 bytes, MD5 7d78dc3efaec8ea3f1801335329f410d.
It inflates to 4,329,897,984 bytes.

Mountable only if the fix of kern/48787 is applied.

-----------------------------------------------------------------


Have a nice day :)

Thomas