ubc_uiomove returns EINVAL

[Emmanuel Dreyfus]

Hi

I am working on PUFFS page cache write-once: before entering data in the
page cache, we must make sure the backend storage is available,
otherwise we will not be able to flush the cache later. Flush may fail
because of EDQUOT or ENOSPC, which lets processes stuck in DE state
(exiting, disk I/O in progress).

The idea is that when file grows, or if file is known to be sparse
(because its allocated block size is lower than its size), then before
entering data in cache, we first read from the file and rewrite to make
sure backend is allocated. I do it using ubc_uiomove, but it always
returns me EINVAL. What did I do wrong?

/* sample value: off = 0xa0000, len = 0x20000 */

zbuf = kmem_alloc(len, KM_SLEEP);

iov.iov_base = zbuf;
iov.iov_len = len;

UIO_SETUP_SYSSPACE(&uio);
uio.uio_iov = &iov;
uio.uio_iovcnt = 1;
uio.uio_offset = off;
uio.uio_resid = len;
uio.uio_rw = UIO_READ;

error = ubc_uiomove(&vp->v_uobj, &uio, len,
UVM_ADV_SEQUENTIAL,
UBC_READ|UBC_UNMAP_FLAG(vp));

[Robert Elz]

Date: Fri, 24 Oct 2014 06:27:11 +0200
From: ***@netbsd.org (Emmanuel Dreyfus)
Message-ID: <1lu0c3p.zl4p65r3skkvM%***@netbsd.org>

| I do it using ubc_uiomove, but it always
| returns me EINVAL. What did I do wrong?

Fantastic! I was beginning to think I was the only person who ever
saw that error (though the way I got it was quite different, but it is
the same error, from seemingly the same place ... if you look through
the code you'll find (I think, perhaps I hope) nowhere obvious where
EINVAL is being set.

Is your test running on an amd64 system? If so, any chance you could
repeat the exact same thing in i386 and see if the same error occurs there?

If we can find what's causing it for you, perhaps that will also help fix
the more convoluted setup that causes the same error for me (I have seen
it using puffs for reading, but also - normally - when using a normal kernel.)

kre

[Emmanuel Dreyfus]

Post by Robert Elz
Is your test running on an amd64 system?

No this is a i386 Xen domU

[Robert Elz]

Date: Fri, 24 Oct 2014 07:16:44 +0000
From: Emmanuel Dreyfus <***@netbsd.org>
Message-ID: <***@homeworld.netbsd.org>

| No this is a i386 Xen domU

OK, that's useful - I did not test my problem much on i386, but when I
did the error did not occur - but my error seems intermittent anyway
(at the very least it depends upon kernel size, as when I added some
diagnostics, the error vanished...). In any case, I was not sure if it
was an amd64 problem alone, or something more generic. That you are
seeing it on i386 makes it less likely to be system specific (though
because those two share so much, does not rule it out.)

I doubt XEN is related, the system I saw this on was not running XEN
(but it could be pv driver related, I was (am) using the virtio stuff.)

kre