Re: [uml-devel] 2.4.10 and Swap Type

[Rodrigo S. de C. <rc...@im...>]

On Mon, Oct 08, 2001 at 12:32:35PM -0500, Jeff Dike wrote:
> rc...@im... said:
> > When we check if a pte is present under UML, a swap entry (whose type
> > is 32) will not have the present bit on (as expected), but will "have"
> > _PAGE_PROTNONE on, since 32 was coded to 0x80. That way, pte_present()
> > macro will erroneously return 1.
> 
> Yup, I don't know how that explains your problem, but that looks like a bug.

Normal swap types are from 0 to 31 (MAX_SWAPFILES - 1), what is
encoded to: 

0x00, 0x02, 0x04, ..., 0x3e (vanilla)
0x00, 0x04, 0x08, ..., 0x7c (uml)

I was setting my swap type to MAX_SWAPFILES (32 in 2.4.10), so I would
set the pte to something like

0x??????40 (vanilla)
0x??????80 (uml)

Therefore a pte set to my swap entry (swap type == 32) would be taken
as having _PAGE_PROTNONE bit set, and that means, for the kernel, that
the page is present.

> What is _PAGE_PROTNONE for anyway?  Is it a special Intel broken bit?  Can 
> I just get rid of it?

_PAGE_PROTNONE is used for a mmapped area that has been accessible but
has "lost" its permissions when we used mprotect() with PROT_NONE. The
pages are present, but the present bit will be off. Since the area is
still mmapped to our process, when handling these ptes (changing
protection again, freeing these ptes, and so on), we must return that
the pages are present in order to handle the pages correctly.

So the answer to your last question is no, I don't think you can get
rid of it. It's a Linux trick to handle this issue.

Regards,
-- 
Rodrigo S. de Castro   <rc...@im...>