lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 1 Dec 2006 11:54:05 +0200 From: "Komal Shah" <komal.shah802003@...il.com> To: "Paul Jackson" <pj@....com> Cc: "Paul Mundt" <lethal@...ux-sh.org>, linux-kernel@...r.kernel.org Subject: Re: bitmapĀ_find_free_region and bitmap_full arg doubts On 12/1/06, Paul Jackson <pj@....com> wrote: > > M. R. Brown and Paul Mundt -- take a look at the question at end of this post. > > Komal wrote: > > > > I have attached the test module code. I have confusion about the what > > to pass as second argument of bitmap_find_free_region for 2nd layer > > bitmap. > > > > Do we have to pass "total size of the block...here 128MB" as the > > second argument or no. of bits in that block, which 32768 (128 >> > > PAGE_SHIFT) ? > > > > This confusion arised as store queue implementation (sq.c) of sh arch, > > passes total size of the bitmap (64M) as the second argument instead > > of bits. > > > > Same is the case with bitmap_full, where I have to pass total size of > > the block (here 128MB) instead of no. of bits, in-order it to make my > > test module work correctly. > > A bitmap is essentially an array of bits. The bitmap_* routines should > take a count of how many bits are in the bitmap array (or in your case, > how many bits are in the segment that you expect to be used in that call.) > > So I'm guessing you will be passing L2_BM_BITS for that second argument. > > The call to bitmap_find_free_region(), in arch/sh/kernel/cpu/sh4/sq.c > looks bogus: > > page = bitmap_find_free_region(sq_bitmap, 0x04000000, > get_order(map->size)); > > It says the bitmap has 0x04000000 bits. This would take 0x04000000 / 8 > which is 8388608 (decimal) bytes to hold. That's an insanely > huge bitmap - 8 million bytes worth of bits. > > I can't make entire sense of the the code you attached. I get confused > over the various sizes of maps and what the maps represent, and of bits > and bytes, and of the two levels. > > When you do call bitmap_find_free_region(), you should pass the number > of bits that are in that segment of the L2 bitmap, which I would guess > is L2_BM_BITS (32 K). > > When you kzalloc() the L2 bitmap for all 16 segments at once, you > should pass the number of -bytes-, not the number of longs. That is, > I guess you want to replace your line: > > bm_l2 = kzalloc(size * L1_BM_NUM_SEGS, GFP_KERNEL); > > with the line: > > bm_l2 = kzalloc(size * L1_BM_NUM_SEGS * sizeof(long), GFP_KERNEL); > > This is because, like most of the *alloc() routines, kzalloc() takes > a byte count, not a long count. The related DECLARE_BITMAP() macro > computes the number of longs, not bytes, but that is because it is > declaring an array of longs, not allocating a number of bytes. > > But I might be entirely confused about what this code is doing. Oops, forgot to reply on this. This code is just a test module in-order to go for layered bitmaps and in-turn understand bitmap_* apis. As I said, requirement was to manage 2GB of virtual space of the co-processor I have attached with ARM11. Now, as we can't allocate single bitmap for 2GB, Paul Mundt suggested to have a layered bitmaps, where 1st bitmap segmenting the virtual space into 128MB blocks and have 2nd layer 128MB size bitmap for each segment in layer 1 bitmap. Hope this clarifies the motivation behind it. -- ---Komal Shah http://komalshah.blogspot.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists