[Barrelfish-users] Maybe a Bug of modify_flags

[Simon Gerber]

Hi Jinghao,

The problem seems to be in the x86_32 version of do_map (in
lib/barrelfish/target/x86_32/pmap_target.c) on line 208, where the
newly created vnode's offset is set to zero instead of i (see also the
attached patch).

Right now, if you modify the flags of the second four kB of a Frame
capability, what you really do is unmap the second four kB and map the
first four kB with the new flags.

Hope this helps,
-- Simon G.

PS:

2012/5/21 Shi Jinghao <jhshi at cs.hku.hk>:
> Hi Simon,
>
> Yes, according to the output, it works correctly on X86_64. But do you have
> any insights about why it would fail on X86_32? Here is my output here with
> arch x86_32 on qemu.
>
> pmaptest.0: begin monothelic_frame test...
> kernel 0: user page fault in 'pmaptest': addr 60000000 IP 400548 error 7
> kernel 0: user page fault in 'pmaptest': addr 60001000 IP 400548 error 7
> pmaptest.0: array init done!
> pmaptest.0: array check fail, a[0] = 1024
> pmaptest.0: two page's content are identical
> a[0] = 1024, a[1024] = 1024
> a[1] = 1025, a[1025] = 1025
> a[2] = 1026, a[1026] = 1026
> a[3] = 1027, a[1027] = 1027
> pmaptest.0: checking if the two virtual page share the same physical page...
> no
> pmaptest.0: begin one_page_one_frame test...
> kernel 0: user page fault in 'pmaptest': addr 68000000 IP 4007b0 error 7
> kernel 0: user page fault in 'pmaptest': addr 68001000 IP 4007b0 error 7
> pmaptest.0: array init done
> pmaptest.0: array check done!
>
> During the porting, I've only changed find_ptable to get_ptable, Is it a
> problem?
>
> For you convenience, I attached a patch for
> /lib/barrelfish/target/x86_32/pmap_target.c:modify_flags, in case you want
> to test it by yourself.
>
> Thanks for your concern!
>
> Jinghao
>
> On Mon, May 21, 2012 at 8:08 PM, Simon Peter <speter at inf.ethz.ch> wrote:
>>
>> Hi Jinghao,
>>
>> I've compiled your code for x86-64 and ran it on QEMU. Here's the output I
>> get:
>>
>> pmaptest.0: begin monothelic_frame test...
>> kernel 0: user page fault in 'pmaptest': addr 60000000 IP 4003a0, error
>> 0x7
>> kernel 0: user page fault in 'pmaptest': addr 60001000 IP 4003a0, error
>> 0x7
>> pmaptest.0: array init done!
>> pmaptest.0: begin one_page_one_frame test...
>> kernel 0: user page fault in 'pmaptest': addr 68000000 IP 400560, error
>> 0x7
>> kernel 0: user page fault in 'pmaptest': addr 68001000 IP 400560, error
>> 0x7
>> pmaptest.0: array init done
>> pmaptest.0: array check done!
>>
>> This seems to be working?
>>
>> Simon
>>
>> On 20.05.2012 16:00, jhshi at cs.hku.hk wrote:
>>>
>>> Here is my previous email, FYI.
>>>
>>> https://lists.inf.ethz.ch/pipermail/barrelfish-users/2012-May/000593.html
>>>
>>> Quoting jhshi at cs.hku.hk:
>>>
>>>>
>>>> Hi,
>>>>
>>>> For some reason, I need to work on x86_32 instead of x86_64. And I
>>>> found that x86_32's pmap->f.modify_flags is NYI. So I ported it from
>>>>  x86_64, as described by my previous email (link). But then I found
>>>> that the port won't work properly. Personally, I don't think the
>>>> problem lies in the porting but in the modify_flags itself.
>>>>
>>>> Here is my test case workflow:
>>>>
>>>> First allocate two pages using frame_alloc and map them at some
>>>> "safe"  virtual address as read-only using pmap->f.map. Then fill
>>>> the two  pages with different content. Since they are read-only,
>>>> page faults  will occur when filling. I catch them and map the fault
>>>> page as  read-write using pmap->f.modify_flags in the fault handler.
>>>> But then I  found that the two page's content are identical, which
>>>> is not supposed  to be.
>>>>
>>>> Then I found that if I allocate one frame for each page, instead of
>>>> one monolithic frame, everything is fine.
>>>>
>>>> I've summarized my test in the attached C file, which should be
>>>> compiled and run under x86_32. Apology for not being able to test it
>>>>  under X86_64 since I encounter some weird errors when compiling
>>>> arch  x86_64. But if you substitute all the X86_32 to X86_64 in the
>>>> test  file, it should work under x86_64 as well.
>>>>
>>>> However, if the test goes all fine under x86_64, then please give
>>>> some  hint about why its x86_32's port would fail.
>>>>
>>>> Thanks in advance!
>>>>
>>>> Regards,
>>>> Jinghao
>>>>
>>>
>>>
>>> _______________________________________________
>>> Barrelfish-users mailing list
>>> Barrelfish-users at lists.inf.ethz.ch
>>> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users
>>
>>
>
>
> _______________________________________________
> Barrelfish-users mailing list
> Barrelfish-users at lists.inf.ethz.ch
> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pmap_map_x86_32.patch
Type: application/octet-stream
Size: 458 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20120521/edbcad1a/attachment.obj