Re: Bug in fs/cd9660 raises questions about inode number computing

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

Hi,

i think i found answers to my questions.

- The inode computation in isodirino() is not necessarily faulty.
  Possibly i misunderstood the meaning of ECMA-119,
  "9.4.2 Extended Attribute Record length".

- The inode numbers (which currently are byte addresses of
  directory records) can be scaled down by a factor of 32.

Further i found the mechanism by which the 32 bit rollover in
isodirino() causes the failed mount:
cd9660_vfsops.c reverse computes the block number of a directory
entry from its inode number.

This will lead to two patch proposals:

- Fix only the rollover.

- Scale down the inode numbers so that they stay below 32 bit
  for directory locations below 128 GiB. (I wrote "TiB" in my
  previous mail. That is wrong, of course.)

How to properly submit them ?

Details:
----------------------------------------------------------------
The RRIP related part that reacts sour on the 32-bit rollover
of isodirino() is in sys/fs/cd9660/cd9660_vfsops.c:812

        if (relocated) {
                /*
                 * On relocated directories we must
                 * read the `.' entry out of a dir.
                 */
                ip->iso_start = ino >> imp->im_bshift;

where
        struct iso_node *ip;
and
  struct iso_node {
        ...
        unsigned long iso_start;                /* [...] */

So the inode number computation is supposed to provide a message
for a program part that wants to know the block number of a
directory entry.

Well, by providing an according reverse computation macro
i could save my plan of 32 bit inode numbers up to 128 GiB.
(Actually i need two block-byte-to-inode macros. One for ISO
 blocks and one for DEV_BSHIFT blocks.)

Now the mounted ISO root directory looks like this:

  netbsd# ls -li /mnt
  total 16777244
  135294151 -rw-r--r--  1 thomas  dbus         396 Aug 26  2011 id_rsa.pub
  135294272 drwxr-xr-x  1 thomas  dbus        6144 Aug  7  2013 libburn-1.3.2
  135296128 drwxr-xr-x  1 thomas  dbus        6144 Dec 12 12:14 libburn-1.3.4
  135297984 drwxr-xr-x  1 thomas  dbus        6144 Mar 18 12:40 libburn-1.3.6
  135294170 -rw-r--r--  1 thomas  dbus  4294965248 Jun 23  2012 powerpc.img
  135294170 -rw-r--r--  1 thomas  dbus  4294965248 Jun 23  2012 powerpc.img

(There is still some work to do with large files.)

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

Further i got a partial answer to my question why isodirino()
encodes ext_attr_length like a block offset.
After using the reverse computed ip->iso_start underneath
the boss vnode vp of ip, there is in cd9660_vfsops.c:

        ip->iso_start = isonum_711(isodir->ext_attr_length) + ip->iso_extent;

Still strange that ext_attr_length is added to the block address
iso_extent.

Would anybody read from this ECMA-119 description that the
value in question is a block count ?
  "9.4.2 Extended Attribute Record length (BP 2)
   This field shall contain an 8-bit number. This number shall specify
   the assigned Extended Attribute Record length if an Extended
   Attribute Record is recorded. Otherwise this number shall be
   zero."

Shrug.
I never saw an ISO with non-zero values in those fields.

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

Have a nice day :)

Thomas