Re: EINVAL from copyin/out - how?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 13 Aug 2014 07:28:52 +0700
    From:        Robert Elz <kre%munnari.OZ.AU@localhost>
    Message-ID:  <15193.1407889732%perseus.noi.kre.to@localhost>

  | I am going to keep hunting [...]

I have added port-amd64 to the To list, since it might help to get
amd64 expertise to make some suggestions... (you can look for the
few earlier messages on tech-kern - or a very brief summary is that
copyout (for read sys calls) or copyin (write of mmap'd file) generating
EINVAL when attempting to read (some) files from a cd9660 filesystem on a DVD).

I have now tried this on an i386 (relatively) current kernel, and
get no problems reading the DVD there - amd64 is the only other
architecture I have available that I can reasonably test on...

I have also found that the problem is non-deterministic, sometimes it
all works just fine.   I found a DVD image (just 2.1GiB, so a fairly
small one...) lying around, that I also had burned to a DVD.   That one
(the DVD) also gave errors (and it seems as if all the errors - the EINVAL
on copyout) happen on files in 3rd level directories (don't know about
deeper, there were none of those - but it looked as if all the files in
the 3rd level directories (that is, root of the dvd, 2nd level subdir made
in root, 3rd level subdir made in the 2nd level subdir - files in the 3rd
level subdir) caused EINVAL when tar attempts to read them (or cp attempts to
write files from the dvd that have been mmap'd).  The EINVAL comes from the
read (r write) of the first block.

I copied the image file to the test system, vnconfig, mount, and no problems
reading the files from that - that was the image that was written to the DVD
(not recreated or anything like that).

At this point it looks to be some kind of setup problem on amd64, when it
reads nested directories, building some data struct that resuts in EINVAL
from the copyout ... (I still have no idea where the EIVAL originates.)

However, just for "fun" I thought I'd do a diff -r of the mount points
of the real DVD (/cdrom) and the mounted vnd0a (/mnt) - that completed
without error.

What's more, after that, tar had no problem reading the DVD either!
(I had not tried tar on this image since the test system was rebooted).

I'm still looking for suggestions as to likely (or even possible) sources
of EINVAL from copyout - copyout itself never generates that, so some kind
of fault must be setting it - but what?   If anyone has any suggestiions for
possible sources, I'll happily mangle my kernel and have it printf whenever
EINVAL is generated (in a plausible place - I don't have the patience to
go adding printfs to every place EIVAL occurs anywhere in the kernel...  just
the places that might make sense.)

kre

ps: I can make the 2.1GiB .iso image available, privately, to anyone who
wants to take a look .. it is just pkgsrc distfiles - I have not checked
though to verify that none of them have "no redistribution" licences, so I
am not going to put it anywhere public.  E-mail me privately if you want
a URL from which you can ftp the image (and be prepared for it to take quite
a while to copy).    I attempted to test this with a very small test DVD
(juft a few hundred KB in all) but that wouldn't fail for me ...  Of course,
the non-deterinism makes it hard to be certain of anything - all I know for
sure is that I have seen the DVD made from the image in question generate
EINVAL when read with tar on a 4.99.49 amd64 kernel.