Re: unmap() sometimes unmaps more pages than specified

[Frank Mehnert]
> On Thursday 22 June 2006 12:48, Espen Skoglund wrote:
>> [Frank Mehnert]
>> 
>>> Hi,
>>> in a complex scenario I observed that the unmap() syscall
>>> sometimes flushes more pages than specified. So far I could not
>>> find a small testcase and therefore have to provide tracelogs of
>>> my current scenario:
>> 
>> [...]
>> 
>>> Please tell me if you need more information.
>> 
>> What happened in this scenario was that you had a 4MB mapping that
>> had two 4KB mappings mapped into the destination space.  You tried
>> to unmap a 4KB mapping in the source space, but there was only a
>> 4MB mapping there.  The whole 4MB mapping was as such unmapped
>> instead.
>> 
>> The policy used to be different for early implementations; i.e.,
>> instead of unmapping the 4MB page the whole unmap operation was
>> ignored.  Completely ignoring the operation is not a good idea,
>> though.

> Ok, that means that, from the point of the destinations' space view,
> L4_Unmap(f=0) called from the destination space is different from
> L4_Unmap(f=1) called from the source space, right? This is _very_
> difficult to handle for me. I guess you want/can not change the
> implementation to consider the outgoing map relations.

Uh... some confusion here.  Does f=0 here mean unmap and f=1 mean
flush?  Let's try to clear it up:

You have two spaces A and B.  A has a 4MB page mapping.  B has
received a 4KB page mapping from A.  Currently we have:

  (1)  A.Flush(4K) == A.Flush(4M) since A has a 4MB mapping.
  (2)  Likewise A.Unmap(4K) == A.Unmap(4M) since A has a 4MB mapping.
  (3)  B.Flush(4K) is fine since B has a 4KB mapping.
  (4)  Consequently A.Unmap(4K) != B.Flush(4K).

I guess (4) is what you find difficult to handle, right?  This would
work fine if (2) was not the case.  Currently the implementation does
(obviously) not behave this way.  I'll give some thought to how this
could most easily be handled.  The behaviour also raises some
questions about the semantics of resetting/reading reference bits, but
I think this could possibly be sorted out.

	eSk