tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

EINVAL from copyin/out - how?



I am trying to debug a problem with cd9660 fs reading in NetBSD current
(and I presume in 7 BETA) - some files generate EINVAL when read (on
older NetBSDs the same disc reads just fine).

I have traced the source of the EINVAL to copyout (or copyin when using
a utility that reads files using mmap()/write()), but I cannot find any way for
copyout (or copyin) to ever return anything other than success or EFAULT,
so I am currently lost explaining the EINVAL...

Can anyone suggest where the EINVAL may be coming from, and what potential
causes might be?   copyout(9) only mentions EFAULT as a possible error (or
does in the older man pages I have available to read at the minute.)

This is on amd64 - I am actually debugging on 6.99.47 kernel sources (a
version I had lying around convenient) - but the same error occurs on 6.99.49
and going back quite a few versions (I think I may have first seen it in
6.99.30 or there about - but I don't run anything even close to all
versions, so this is no evidence as to when the problem started - I am
guessing at the changes to the cd9660 fs code several months ago.  The disc
(a DVD, but I have also see it on BD) reads fine on a 6.99.17 i386 system.

Most files read OK, only a few have "issues" (error is always EINVAL).
Directory reads all look fine, only file reds give problems.

Tracing goes from cd9660_read() (error detected from call to ubc_uiomove())
down to copyout_vmspace() where the error comes from the copyout() call
that is done when the current process is the one whose vmspace is wanted.

That is ...

        if (__predict_true(vm == curproc->p_vmspace)) {
                return copyout(kaddr, uaddr, len);
        }

those few lines end up doing return(EINVAL).

How?

copyout is from amd64/copy.S and while my x86 assembler skill is close to
0, even I can grep for EINVAL, 22, and 16, and upon finding none of those
(anywhere in the file) conclude that it would be difficult for copyout to
actually return EINVAL.

Any clues?   If I can understand this, I may be able to track down what
changed between 6.99.17 and current that is causing these problems.

kre

ps: the disc (DVD or BD) in question was generated on NetBSD, using
mkisofs (from pkgsrc) - more or less using the cddist script from the
pkgtools/cdpack package (the mkisofs call is essentially identical,
I get the files into the directories to put on the DVD in a slightly
different manner than the script does.  It is also not just one disc
that might have some weird issue - many discs I have made using the same
procedure have similar problems (EINVAL always) - even my 6.99.47 install
DVD (on which I include source sets) gave me EINVAL when I was trying to
extract the sources to start this debug ... I used the older kernel to
extract them.



Home | Main Index | Thread Index | Old Index