libunwind-devel
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]