[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] mincore_validate fails sometimes
From: |
Dave Watson |
Subject: |
Re: [Libunwind-devel] mincore_validate fails sometimes |
Date: |
Wed, 17 Jan 2018 07:58:52 -0800 |
User-agent: |
Mutt/1.6.0 (2016-04-01) |
On 01/17/18 09:28 AM, Daniel Vassdal wrote:
> Hi Dave,
> Thanks for your reply.
>
> Maybe I wasn't being entirely clear; the call to mincore() itself succeeded,
> i.e. returned 0.
> However, when the result array is checked, one or more of the pages are not
> in memory.
Ah, ok.
> If we have a look at commit bc8698fd, part of the commit comment says:
> > we should also check that the pages are mapped, through the passed mvec
> > array. This patch
> > also adds this verification.
>
> I think the code that part of the code the comment refers to is this:
> > for (i = 0; i < (len + PAGE_SIZE - 1) / PAGE_SIZE; i++)
> > {
> > if (!(mvec[i] & 1)) return -1;
> > }
>
> I'm not sure this is correct. According to the man page for mincore:
> > mincore() returns a vector that indicates whether pages of the
> > calling process's virtual memory are resident in core (RAM), and so
> > will not cause a disk access (page fault) if referenced.
>
> Is this what the author intended to check?
Yes, it's meant to check that the pages are mapped in. Do you think
the above code is incorrect?
>
> Furthermore, the man page states hat mincore() can return
> > ENOMEM addr to addr + length contained unmapped memory.
>
> Thus it looks to me as if mincore() already returns an error code for what
> the comment says the block above is checking for.
> This is a little out of my comfort zone so I may be talking nonsense, but
> maybe have a look at it?
I think this means ENOMEM is returned only if *all* pages are
unmapped, but the vector must be checked if only some of the pages are
unmapped.