[NSWI004] Assignment 5: Bitmap shrinks unexpectedly

[Péťa Emmerová]

Thank you very much for the reply.

We treated frame allocator similarly as kmalloc, so we tried to start right
next to the kernel end, and reserve our first frame for the bitmap and its
data. (The frame starts right after kernel_end.) Then we try to split
memory for heap and frame allocator.
Do we have a bug in our approach?

po 6. 1. 2020 v 17:12 odesílatel Vojtech Horky <horky at d3s.mff.cuni.cz>
napsal:

> Hello.
>
> Dne 06. 01. 20 v 16:47 Péťa Emmerová napsal(a):
> > Hello,
> > we decided to use a bitmap for frame allocator. Firstly, we initialize
> > bitmap in frame_init, and then print out the length of it, which seems
> > to be fine. We then try to allocate the frames after the bitmap. But
> > then, when we take a look at bitmap's length during a frame allocation,
> > it's length unexpectedly drops to 16. Moreover, although all frames in
> > bitmap should be set to zero, they aren't, they contain random values.
> > We would appreciate any help or hint how to work with the heap.
> > Sincerely, Team Datel
>
> This sounds like a memory corruption. Have you shifted start of the
> frames by the size of the storage for the bitmap?
>
> Looking at your code (f41f9d8a0), I think you do not account for the
> fact that kernel occupies the first few frames of the physical memory.
>
> BTW, you have unreachable code in frame_free() and you do not restore
> interrupts properly.
>
> Hope this helps,
> - VH
> _______________________________________________
> NSWI004 mailing list
> NSWI004 at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20200106/7fdf0bda/attachment.html>