Re: ubc_uiomove returns EINVAL

[Chuck Silvers <chuq%chuq.com@localhost>]

On Sat, Oct 25, 2014 at 12:33:44AM +0700, Robert Elz wrote:
>     Date:        Fri, 24 Oct 2014 09:49:03 -0700
>     From:        Chuck Silvers <chuq%chuq.com@localhost>
>     Message-ID:  <20141024164903.GA29200%spathi.chuq.com@localhost>
> 
>   | which is probably coming from
>   | VOP_GETPAGES() of the vnode you're trying to access with ubc_uiomove().
> 
> This is the best clue on where to look next yet, thanks ... I assume
> that must be from uvn_get() (in uvm_vnode.c) and is almost certainly
> from
> 
>         error = uobj->pgops->pgo_get(uobj, uoff, &pg, &gotpages,
>             0, flt->access_type & MASK(ufi->entry), ufi->entry->advice,
>             PGO_SYNCIO);
> 
> in uvm_fault_lower_io() (uvm_fault.c) - that looks to be the only place
> where VOP_GETPAGES() can get called from uvm_fault and actually return
> an error (there's another place where the error, if any, looks to be ignored).
> 
> Does that sound reasonable, or am I missing something?

yup, that sounds right.


> I see that this should be able to be tracked using the UVMHIST (aka KERNHIST)
> stuff, but assuming I build a kernel with that enabled, how do I get access
> to the data it collects?   I see it available via DDB, but is that the only
> way, or is there some userland tool that can extract it?

vmstat has "-l" and "-u" options to extract these.


> This is, of course, just to verify that's the source of the error .. will
> still need to look inside VOP_GETPAGES() (in the code it runs) to figure
> out why it wants to return EINVAL, but one step at a time.
> 
> kre

-Chuck