Re: EINVAL from copyin/out - how?

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

Hi,

> the tar file read loop is basically
>        while ((n = read(fd, buf, bufzize)) > 0)
>                write(ofd, buf, n);

That would be regular file content and thus should touch
cd9660_bmap(), which would translate the file-internal block
number to the partition/device block number.

man 9 VOP_BMAP says:
  "In case the logical block is not allocated, -1 is used."
But cd9660_bmap() does never set *ap->a_bnp to this value.
It happily computes the device block number from file start
block and desired file-internal block number.
On the other hand, a sane ISO 9660 filesystem should not
cause any block to be read which lies outside its hosting
device.

I assume read(2) or its helpers call VOP_BMAP(9) with the
vnode of the data file and then bread(9) with the device
vnode and the converted block number.

There is also cd9660_read()/VOP_READ(9) which i do not really
understand in the (vp->v_type == VREG) case. Especially i do
not see where the necessary file-to-device mapping is done.


In any case, i'd deem some printfs in cd9660_bmap() worthwhile
as long as there are no better ideas.
They should tell about the eventual emergency exit:
        if (ap->a_bnp == NULL)
                return (0);
resp. about the sucessfully mapped parameters:
  af->a_bn , *af->a_bnp, *af->a_runp (if af->a_runp != NULL)


One should also find out, whether cd9660_read() is called
in the course of read(2) on a regular file.
        if (vp->v_type == VREG) {
                const int advice = IO_ADV_DECODE(ap->a_ioflag);

                printf("cd9660_read() called\n");

                ...
        }
(In that case one would have to learn how this function actually
 works by help of ubc_uiomove(9) resp. how ubc_uiomove(9) learns
 about the data block numbers of the regular file.)


> The read() returns -1, with errno == EINVAL

Well, cd9660 has a few EINVALs. But except one in cd9660_read()
        if (uio->uio_offset < 0)
                return (EINVAL);
i cannot spot any other which would be suspicious to happen
underneath read(2).
(The others have to do with mounting, readdir, readlink, ...)

And overall we still lack an architecture specific trigger
for any error condition in cd9660.


Have a nice day :)

Thomas