On Sunday 16 July 2006 9:12 pm, David Miller wrote: > From: Paul Moore <[EMAIL PROTECTED]> > Date: Sun, 16 Jul 2006 12:10:44 -0400 > > > On Friday 14 July 2006 10:03 pm, James Morris wrote: > > > On Fri, 14 Jul 2006, [EMAIL PROTECTED] wrote: > > > > +/** > > > > + * cipso_v4_bitmap_walk - Walk a bitmap looking for a bit > > > > > > > > + * cipso_v4_bitmap_setbit - Sets a single bit in a bitmap > > > > > > Can you use lib/bitmap.c instead? > > > > Looking again at include/asm/bitops.h I think I now remember why I > > decided not to use them in the first place. > > lib/bitmap.c and the asm/bitops.h operations are two entirely > different animals.
I probably should have been more clear - I didn't see anything in lib/bitmap.c (or include/linux/bitmap.h) that I think would have been useful. However, include/linux/bitmap.h makes reference to asm/bitops.h which does have some function which may have been useful if they didn't have the length restrictions. > Wrt. your asm/bitops.h concerns, is there any reason you cannot pad > out your bitmaps to be a modulo of "long" which is required for > those routines? Right now I use both the bitmap_walk() and bitmap_setbit() routines to deal with both CIPSO tags straight from the sk_buff as well as the internal bitmap representation. Padding out the internal bitmaps would require some code changes but there isn't much I can do about the packet I don't believe. True it would probably be okay for most packets to assume you could access an entire "long"s worth of memory but then again it would only take one evil packet to start causing problems ... -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
