On Wed, Mar 25, 2020 at 01:54:51AM +0530, Neeraj Pal wrote:
> Hi Otto,
>
> I am having two small issues or confusions:
>
> First Query:
>
> 885 /*
> 886 * Allocate a page of chunks
> 887 */
> 888 static struct chunk_info *
> 889 omalloc_make_chunks(struct dir_info *d, int bits, int listnum)
> 890 {
> 891 struct chunk_info *bp;
> 892 void *pp;
> 893
> 894 /* Allocate a new bucket */
> 895 pp = map(d, NULL, MALLOC_PAGESIZE, 0);
> 896 if (pp == MAP_FAILED)
> 897 return NULL;
> 898
> 899 /* memory protect the page allocated in the malloc(0) case */
> 900 if (bits == 0 && mprotect(pp, MALLOC_PAGESIZE, PROT_NONE) ==
> -1)
> 901 goto err;
> 902
> 903 bp = alloc_chunk_info(d, bits);
> 904 if (bp == NULL)
> 905 goto err;
> 906 bp->page = pp;
> 907
> 908 if (insert(d, (void *)((uintptr_t)pp | (bits + 1)),
> (uintptr_t)bp,
> 909 NULL))
> 910 goto err;
> 911 LIST_INSERT_HEAD(&d->chunk_dir[bits][listnum], bp, entries);
> 912 return bp;
> 913
> 914 err:
> 915 unmap(d, pp, MALLOC_PAGESIZE, 0, d->malloc_junk);
> 916 return NULL;
> 917 }
>
> So, actually, as per the comment on line no. 885 in the above code, it is
> mentioned that it will allocate a page of chunks. But, what I have observed
> as from the code that pp is the new bucket means pp is the page which is
> full of chunks or which has chunks. As we can see on line 905, it calls
> alloc_chunk_info() function then inside that it calls init_chunk_info(),
> so, in short, we can say that first, it will allocate some chunk and then
> initialized that allocated chunk and then returns the same.
pp points to a page of chunks
bp point to the associated meta info: a bitmap that says which chunks
in the page are free. The bitmap is an aray of shorts, so 16 bits per entry.
>
> So, if we compare from here then it means, bp is the allocated and
> initialized chunk and the bp->page = pp, means it stores the page pp to
> bp->page. Then, after the hash table, it returns bp, means it returns the
> allocated-initialized chunk. But at the same time, I was referring the
> https://junk.tintagel.pl/openbsd-daily-malloc-3.txt by @mulander where he
> mentioned that "so bp is a page of chunks". So, I became little confused
> because pp is the page of chunks, which is used in function malloc_bytes()
> where it calculates the page offset and adds it to page bp->page, which is
> used by the user to input or writes stuff, like it returns address bp->page
> + k addr returns by malloc(3).
again bp is the meta info. bp->page is the page of chunks itself
>
> Second Query:
>
> And, bp->page is the pp and k is the offset, so, is it possible to get the
> address of the specific chunk because (bp->page + k) belongs to some chunks
> or we can say k is the index of the chunk that is inside the bucket
> bp->page or pp?
in the code k is first is the chunk number, and then multiplied (by
shifting it by bp->shift) to get the byte offset of the chunk inside
the chunk page.
>
>
> And in the structure chunk_info, u_short bits[1] is the bit for tracking
> whether the chunk is free or not. So, it belongs to each and every chunk.
> For example, there are 10 chunks in a page and 5fth chunk is not free then
> it will set that bits[1] to 0 and other 9 will be 1.
>
> OR
>
> Is it like bits denote the bits, like in the function init_chunk_info, in
> the end, it copies 0xff bytes to p->bits with size 30. Then it calculates
> p->bits[15] = 65535, so it is like it makes the last bit to 1.
p->bits is a bit mask. Each short in it holds 16 bits, so the first 16
chunks end uo in the first short, the next in the 2nd short etc.
The *lp ^= 1 << k line actuall sets the bit.
> sometimes I also have things in my mind like if bits[1] then how it is
> possible to assignbits[15] it means it performs the operation on bits. that
> I have analyzed by debugging.
>
> I have referred the paper for the understanding of bits[1] value,
> http://www.ouah.org/BSD-heap-smashing.txt. Actually not have proper
> confidence of understanding on bits logic.
>
> Apart from the issues discussed above, I mostly understood most of the
> stuff on malloc(3) but for the above still not getting the convinsible
> understainding.
>
>
> Regards,
> Neeraj
