linux-toradex.git/lib/bitmap.c, branch v2.6.25-rc2

Fix bitmap_scnlistprintf for empty masks

2007-11-05T23:12:32+00:00

When a bitmap is empty bitmap_scnlistprintf() would leave the buffer
uninitialized.  Set it to an empty string in this case.

I didn't see any in normal kernel callers hitting this, but some custom
debug code of mine did.

Signed-off-by: Andi Kleen 
Acked-by: Paul Jackson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] kernel-doc fixes for 2.6.20-git15 (non-drivers)

2007-03-01T22:53:37+00:00

Fix kernel-doc warnings in 2.6.20-git15 (lib/, mm/, kernel/, include/).

Signed-off-by: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Numerous fixes to kernel-doc info in source files.

2007-02-11T18:51:32+00:00

A variety of (mostly) innocuous fixes to the embedded kernel-doc content in
source files, including:

  * make multi-line initial descriptions single line
  * denote some function names, constants and structs as such
  * change erroneous opening '/*' to '/**' in a few places
  * reword some text for clarity

Signed-off-by: Robert P. J. Day 
Cc: "Randy.Dunlap" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] bitmap: parse input from kernel and user buffers

2006-10-11T18:14:22+00:00

lib/bitmap.c:bitmap_parse() is a library function that received as input a
user buffer.  This seemed to have originated from the way the write_proc
function of the /proc filesystem operates.

This has been reworked to not use kmalloc and eliminates a lot of
get_user() overhead by performing one access_ok before using __get_user().

We need to test if we are in kernel or user space (is_user) and access the
buffer differently.  We cannot use __get_user() to access kernel addresses
in all cases, for example in architectures with separate address space for
kernel and user.

This function will be useful for other uses as well; for example, taking
input for /sysfs instead of /proc, so it was changed to accept kernel
buffers.  We have this use for the Linux UWB project, as part as the
upcoming bandwidth allocator code.

Only a few routines used this function and they were changed too.

Signed-off-by: Reinette Chatre 
Signed-off-by: Inaky Perez-Gonzalez 
Cc: Paul Jackson 
Cc: Joe Korty 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] kernel-doc for lib/bitmap.c

2006-06-25T17:01:20+00:00

Make corrections/fixes to kernel-doc in lib/bitmap.c and include it in DocBook
template.

Signed-off-by: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] bitops: hweight() related cleanup

2006-03-26T16:57:15+00:00

By defining generic hweight*() routines

- hweight64() will be defined on all architectures
- hweight_long() will use architecture optimized hweight32() or hweight64()

I found two possible cleanups by these reasons.

Signed-off-by: Akinobu Mita 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] bitmap: region restructuring

2006-03-24T15:33:20+00:00

Restructure the bitmap_*_region() operations, to avoid code duplication.

Also reduces binary text size by about 100 bytes (ia64 arch).  The original
Bottomley bitmap_*_region patch added about 1000 bytes of compiled kernel text
(ia64).  The Mundt multiword extension added another 600 bytes, and this
restructuring patch gets back about 100 bytes.

But the real motivation was the reduced amount of duplicated code.

Tested by Paul Mundt using <= BITS_PER_LONG as well as power of
2 aligned multiword spanning allocations.

Signed-off-by: Paul Mundt 
Signed-off-by: Paul Jackson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] bitmap: region multiword spanning support

2006-03-24T15:33:20+00:00

Add support to the lib/bitmap.c bitmap_*_region() routines

For bitmap regions larger than one word (nbits > BITS_PER_LONG).  This removes
a BUG_ON() in lib bitmap.

I have an updated store queue API for SH that is currently using this with
relative success, and at first glance, it seems like this could be useful for
x86 (arch/i386/kernel/pci-dma.c) as well.  Particularly for anything using
dma_declare_coherent_memory() on large areas and that attempts to allocate
large buffers from that space.

Paul Jackson also did some cleanup to this patch.

Signed-off-by: Paul Mundt 
Signed-off-by: Paul Jackson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] bitmap: region cleanup

2006-03-24T15:33:20+00:00

Paul Mundt  says:

This patch set implements a number of patches to clean up and restructure the
bitmap region code, in addition to extending the interface to support
multiword spanning allocations.

The current implementation (before this patch set) is limited by only being
able to allocate pages <= BITS_PER_LONG, as noted by the strategically
positioned BUG_ON() at lib/bitmap.c:752:

        /* We don't do regions of pages > BITS_PER_LONG.  The
	 * algorithm would be a simple look for multiple zeros in the
	 * array, but there's no driver today that needs this.  If you
	 * trip this BUG(), you get to code it... */
        BUG_ON(pages > BITS_PER_LONG);

As I seem to have been the first person to trigger this, the result ends up
being the following patch set with the help of Paul Jackson.

The final patch in the series eliminates quite a bit of code duplication, so
the bitmap code size ends up being smaller than the current implementation as
an added bonus.

After these are applied, it should already be possible to do multiword
allocations with dma_alloc_coherent() out of ranges established by
dma_declare_coherent_memory() on x86 without having to change any of the code,
and the SH store queue API will follow up on this as the other user that needs
support for this.

This patch:

Some code cleanup on the lib/bitmap.c bitmap_*_region() routines:

 * spacing
 * variable names
 * comments

Has no change to code function.

Signed-off-by: Paul Mundt 
Signed-off-by: Paul Jackson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] cpuset: better bitmap remap defaults

2006-01-09T04:13:42+00:00

Fix the default behaviour for the remap operators in bitmap, cpumask and
nodemask.

As previously submitted, the pair of masks  defined a map of the
positions of the set bits in A to the corresponding bits in B.  This is still
true.

The issue is how to map the other positions, corresponding to the unset (0)
bits in A.  As previously submitted, they were all mapped to the first set bit
position in B, a constant map.

When I tried to code per-vma mempolicy rebinding using these remap operators,
I realized this was wrong.

This patch changes the default to map all the unset bit positions in A to the
same positions in B, the identity map.

For example, if A has bits 4-7 set, and B has bits 9-12 set, then the map
defined by the pair  maps each bit position in the first 32 bits as
follows:

	0 ==> 0
	  ...
	3 ==> 3
	4 ==> 9
	  ...
	7 ==> 12
	8 ==> 8
	9 ==> 9
	  ...
	31 ==> 31

This now corresponds to the typical behaviour desired when migrating pages and
policies from one cpuset to another.

The pages on nodes within the original cpuset, and the references in memory
policies to nodes within the original cpuset, are migrated to the
corresponding cpuset-relative nodes in the destination cpuset.  Other pages
and node references are left untouched.

Signed-off-by: Paul Jackson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds