[Barrelfish-users] Maybe a Bug of modify_flags

[Shi Jinghao]

Yes, your explanation and patch solve the pain. Thanks very much!

Regards,
Jinghao

On Mon, May 21, 2012 at 9:11 PM, Simon Gerber <simugerber at student.ethz.ch>wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20120521/a0c5d09f/attachment-0001.html