qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v19 3/7] xbitmap: add more operations


From: Wei Wang
Subject: Re: [Qemu-devel] [PATCH v19 3/7] xbitmap: add more operations
Date: Sat, 16 Dec 2017 18:14:12 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 12/15/2017 12:29 AM, Tetsuo Handa wrote:
Wei Wang wrote:
I used the example of xb_clear_bit_range(), and xb_find_next_bit() is
the same fundamentally. Please let me know if anywhere still looks fuzzy.
I don't think it is the same for xb_find_next_bit() with set == 0.

+               if (radix_tree_exception(bmap)) {
+                       unsigned long tmp = (unsigned long)bmap;
+                       unsigned long ebit = bit + 2;
+
+                       if (ebit >= BITS_PER_LONG)
+                               continue;
+                       if (set)
+                               ret = find_next_bit(&tmp, BITS_PER_LONG, ebit);
+                       else
+                               ret = find_next_zero_bit(&tmp, BITS_PER_LONG,
+                                                        ebit);
+                       if (ret < BITS_PER_LONG)
+                               return ret - 2 + IDA_BITMAP_BITS * index;

What I'm saying is that find_next_zero_bit() will not be called if you do
"if (ebit >= BITS_PER_LONG) continue;" before calling find_next_zero_bit().

When scanning 
"0000000000000000000000000000000000000000000000000000000000000001",
"bit < BITS_PER_LONG - 2" case finds "0" in this word but
"bit >= BITS_PER_LONG - 2" case finds "0" in next word or segment.

I can't understand why this is correct behavior. It is too much puzzling.


OK, I'll post out a version without the exceptional path.

Best,
Wei




reply via email to

[Prev in Thread] Current Thread [Next in Thread]