linux-kernel - Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-id: <587D8DE5.6040408@samsung.com>
Date:   Tue, 17 Jan 2017 12:22:13 +0900
From:   Jaewon Kim <jaewon31.kim@...sung.com>
To:     Yury Norov <ynorov@...iumnetworks.com>
Cc:     gregkh@...uxfoundation.org, akpm@...ux-foundation.org,
        labbott@...hat.com, mina86@...a86.com, m.szyprowski@...sung.com,
        gregory.0xf0@...il.com, laurent.pinchart@...asonboard.com,
        akinobu.mita@...il.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, jaewon31.kim@...il.com
Subject: Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size



On 2017년 01월 15일 16:17, Yury Norov wrote:
> Hi Jaewon,
>
> with all comments above, some of my concerns.
>
> On Mon, Dec 26, 2016 at 01:18:11PM +0900, Jaewon Kim wrote:
>> There was no bitmap API which returns both next zero index and size of zeros
>> from that index.
> Yes, there is. Most probably because this function is not needed.
> Typical usecase is looking for the area of N free bits, were caller
> knows N, and doesn't care of free areas smaller than N. There is 
> bitmap_find_next_zero_area() for exactly that.
Hi Yuri
Thank you for comment.
I did not mean finding free area but wanted to know its size.
So bitmap_find_next_zero_area is not what I wanted.
I will not submit this patch though.
>
>> This is helpful to look fragmentation. This is an test code to look size of zeros.
>> Test result is '10+9+994=>1013 found of total: 1024'
>>
>> unsigned long search_idx, found_idx, nr_found_tot;
>> unsigned long bitmap_max;
>> unsigned int nr_found;
>> unsigned long *bitmap;
>>
>> search_idx = nr_found_tot = 0;
>> bitmap_max = 1024;
>> bitmap = kzalloc(BITS_TO_LONGS(bitmap_max) * sizeof(long),
>> 		 GFP_KERNEL);
>>
>> /* test bitmap_set offset, count */
>> bitmap_set(bitmap, 10, 1);
>> bitmap_set(bitmap, 20, 10);
>>
>> for (;;) {
>> 	found_idx = bitmap_find_next_zero_area_and_size(bitmap,
>> 				bitmap_max, search_idx, &nr_found);
>> 	if (found_idx >= bitmap_max)
>> 		break;
>> 	if (nr_found_tot == 0)
>> 		printk("%u", nr_found);
>> 	else
>> 		printk("+%u", nr_found);
>> 	nr_found_tot += nr_found;
>> 	search_idx = found_idx + nr_found;
>> }
>> printk("=>%lu found of total: %lu\n", nr_found_tot, bitmap_max);
>>
>> Signed-off-by: Jaewon Kim <jaewon31.kim@...sung.com>
> This usecase is problematic in real world. Consider 1-byte bitmap
> '01010101'. To store fragmentation information for further analysis,
> you have to allocate 4 pairs of address and size. On 64-bit machine
> it's 64 bytes of additional memory. Brief grepping of kernel sources
> shows that no one does it. Correct me if I missed something.
Sorry but I did not understand for "you have to allocate 4 pairs of address and size"
I used just local variables.
>
> If you still think this API is useful, you'd walk over kernel
> and find bins of code that will become better with your function,
> and send the patch that adds the use of your function there. Probable
> candidates for search are bitmap_find_next_zero_area() and find_next_bit()
> functions.
>
> If the only suitable place for new function is your example below, I
> think it's better not to introduce new API and reconsider your
> implementation instead.
>
> Yury.
>
>
>