similar to: [Bug 1540] New: Incorrect hash in SSH_MSG_KEX_DH_GEX_REPLY

From: Matthew Wilcox <mawilcox at microsoft.com> The eXtensible Bitmap is a sparse bitmap representation which is efficient for set bits which tend to cluster. It supports up to 'unsigned long' worth of bits. Signed-off-by: Matthew Wilcox <mawilcox at microsoft.com> Signed-off-by: Wei Wang <wei.w.wang at intel.com> Cc: Andrew Morton <akpm at linux-foundation.org>

OK, here's a rewrite of xbitmap. Compared to the version you sent: - xb_find_set() is the rewrite I sent out yesterday. - xb_find_clear() is a new implementation. I use the IDR_FREE tag to find clear bits. This led to me finding a bug in radix_tree_for_each_tagged(). - xb_zero() is also a new implementation (replacing xb_clear_bit_range). It should also be more efficient in deep

On Wed, Dec 20, 2017 at 04:13:16PM +0000, Wang, Wei W wrote: > On Wednesday, December 20, 2017 8:26 PM, Matthew Wilcox wrote: > > unsigned long bit; > > xb_preload(GFP_KERNEL); > > xb_set_bit(xb, 700); > > xb_preload_end(); > > bit = xb_find_set(xb, ULONG_MAX, 0); > > assert(bit == 700); > > This above test will result in "!node with bitmap

This patch adds support to find next 1 or 0 bit in a xbmitmap range and clear a range of bits. More possible optimizations to add in the future: 1) xb_set_bit_range: set a range of bits. 2) when searching a bit, if the bit is not found in the slot, move on to the next slot directly. 3) add tags to help searching. Signed-off-by: Wei Wang <wei.w.wang at intel.com> Cc: Matthew Wilcox

From: Matthew Wilcox <mawilcox at microsoft.com> Add the following tests for xbitmap: 1) single bit test: single bit set/clear/find; 2) bit range test: set/clear a range of bits and find a 0 or 1 bit in the range. Signed-off-by: Wei Wang <wei.w.wang at intel.com> Cc: Matthew Wilcox <mawilcox at microsoft.com> Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michael S.

On 11/30/2017 06:34 PM, Tetsuo Handa wrote: > Wei Wang wrote: >> + * @start: the start of the bit range, inclusive >> + * @end: the end of the bit range, inclusive >> + * >> + * This function is used to clear a bit in the xbitmap. If all the bits of the >> + * bitmap are 0, the bitmap will be freed. >> + */ >> +void xb_clear_bit_range(struct xb *xb,

Greetings, Given the weakness with Diffie-Hellman modp groups less than 2048, is it time to bump the suggested 1024 bit minimum value from the RFC 4419 to a more current 2048 value for OpenSSH 7.0? If so, should this be just a compile-time change, or should there be a new client and server runtime option? Thanks, -- Mark

This patch adds support to find next 1 or 0 bit in a xbmitmap range and clear a range of bits. More possible optimizations to add in the future: 1) xb_set_bit_range: set a range of bits. 2) when searching a bit, if the bit is not found in the slot, move on to the next slot directly. 3) add tags to help searching. Signed-off-by: Wei Wang <wei.w.wang at intel.com> Cc: Matthew Wilcox

This patch adds support to find next 1 or 0 bit in a xbmitmap range and clear a range of bits. More possible optimizations to add in the future: 1) xb_set_bit_range: set a range of bits. 2) when searching a bit, if the bit is not found in the slot, move on to the next slot directly. 3) add tags to help searching. Signed-off-by: Wei Wang <wei.w.wang at intel.com> Cc: Matthew Wilcox

As the subject says, building syslinux fails when built against 2.6.8.1 kernel headers. Anybody out there have a patch? The compile errors are below. set -e ; for i in memdisk dos win32 mtools unix extlinux sample com32 ; do make DATE=0x41e470ae HEXDATE=0x41e470ae -C $i all ; done make[1]: Entering directory `/usr/src/syslinux-3.07-pre1/memdisk' make[1]: Nothing to be done for `all'.

I'm commenting without understanding the logic. Wei Wang wrote: > + > +bool xb_preload(gfp_t gfp); > + Want __must_check annotation, for __radix_tree_preload() is marked with __must_check annotation. By error failing to check result of xb_preload() will lead to preemption kept disabled unexpectedly. > +int xb_set_bit(struct xb *xb, unsigned long bit) > +{ > + int err;

I'm commenting without understanding the logic. Wei Wang wrote: > + > +bool xb_preload(gfp_t gfp); > + Want __must_check annotation, for __radix_tree_preload() is marked with __must_check annotation. By error failing to check result of xb_preload() will lead to preemption kept disabled unexpectedly. > +int xb_set_bit(struct xb *xb, unsigned long bit) > +{ > + int err;

On 12/21/2017 10:37 PM, Tetsuo Handa wrote: > Matthew Wilcox wrote: >>> +/** >>> + * xb_find_set - find the next set bit in a range of bits >>> + * @xb: the xbitmap to search from >>> + * @offset: the offset in the range to start searching >>> + * @size: the size of the range >>> + * >>> + * Returns: the found bit or, @size if no

On Mon, Aug 28, 2017 at 06:08:30PM +0800, Wei Wang wrote: > +/** > + * xb_zero - zero a range of bits in the xbitmap > + * @xb: the xbitmap that the bits reside in > + * @start: the start of the range, inclusive > + * @end: the end of the range, inclusive > + */ > +void xb_zero(struct xb *xb, unsigned long start, unsigned long end) > +{ > + unsigned long i; > +

On Mon, Aug 28, 2017 at 06:08:30PM +0800, Wei Wang wrote: > +/** > + * xb_zero - zero a range of bits in the xbitmap > + * @xb: the xbitmap that the bits reside in > + * @start: the start of the range, inclusive > + * @end: the end of the range, inclusive > + */ > +void xb_zero(struct xb *xb, unsigned long start, unsigned long end) > +{ > + unsigned long i; > +

On 12/13/2017 10:16 PM, Tetsuo Handa wrote: > Wei Wang wrote: >> On 12/12/2017 09:20 PM, Tetsuo Handa wrote: >>> Wei Wang wrote: >>>> +void xb_clear_bit_range(struct xb *xb, unsigned long start, unsigned long end) >>>> +{ >>>> + struct radix_tree_root *root = &xb->xbrt; >>>> + struct radix_tree_node *node; >>>> +

Hi, The latest version of R had some changes to functions "readbin() and writeBin() [which] now support raw vectors as well as filenames and connections.". As a result I am working on retiring "raw2bin" and "bin2raw" functions from "caTools" package which do exactly the same. Thanks to Prof. Ripley for bringing this change to my attention. Which brings me

On Saturday, December 16, 2017 3:22 AM, Matthew Wilcox wrote: > On Fri, Dec 15, 2017 at 10:49:15AM -0800, Matthew Wilcox wrote: > > Here's the API I'm looking at right now. The user need take no lock; > > the locking (spinlock) is handled internally to the implementation. Another place I saw your comment " The xb_ API requires you to handle your own locking"

libswfdec/swfdec_bits.c | 81 +++++++++++++++++++++++++++++----------------- libswfdec/swfdec_bits.h | 1 libswfdec/swfdec_sprite.c | 6 --- libswfdec/swfdec_tag.c | 12 ------ 4 files changed, 55 insertions(+), 45 deletions(-) New commits: diff-tree 493905baa1c07054276adb078f086e7ca4acc26b (from parents) Merge: 3dc137aafb42e15340c20a78d1599c714862ba0f

On Fri, Dec 15, 2017 at 10:49:15AM -0800, Matthew Wilcox wrote: > Here's the API I'm looking at right now. The user need take no lock; > the locking (spinlock) is handled internally to the implementation. I looked at the API some more and found some flaws: - how does xbit_alloc communicate back which bit it allocated? - What if xbit_find_set() is called on a completely empty