kernel/linux.git/drivers/md/bitmap.c, branch linux-2.6.22.y

md: don't write more than is required of the last page of a bitmap

2007-05-24T03:14:14+00:00

It is possible that real data or metadata follows the bitmap without full page alignment. So limit the last write to be only the required number of bytes, rounded up to the hard sector size of the device. Signed-off-by: Neil Brown Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Remove do_sync_file_range()

2007-05-08T18:15:04+00:00

Remove do_sync_file_range() and convert callers to just use do_sync_mapping_range(). Signed-off-by: Mark Fasheh Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: fix calculation for size of filemap_attr array in md/bitmap

2007-04-12T22:31:42+00:00

If 'num_pages' were ever 1 more than a multiple of 8 (32bit platforms) or of 16 (64 bit platforms). filemap_attr would be allocated one 'unsigned long' shorter than required. We need a round-up in there. Signed-off-by: Neil Brown Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] remove invalidate_inode_pages()

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

Convert all calls to invalidate_inode_pages() into open-coded calls to invalidate_mapping_pages(). Leave the invalidate_inode_pages() wrapper in place for now, marked as deprecated. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: avoid possible BUG_ON in md bitmap handling

2007-02-09T17:25:47+00:00

md/bitmap tracks how many active write requests are pending on blocks associated with each bit in the bitmap, so that it knows when it can clear the bit (when count hits zero). The counter has 14 bits of space, so if there are ever more than 16383, we cannot cope. Currently the code just calles BUG_ON as "all" drivers have request queue limits much smaller than this. However is seems that some don't. Apparently some multipath configurations can allow more than 16383 concurrent write requests. So, in this unlikely situation, instead of calling BUG_ON we now wait for the count to drop down a bit. This requires a new wait_queue_head, some waiting code, and a wakeup call. Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower in that case...). Signed-off-by: Neil Brown Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: avoid reading past the end of a bitmap file

2007-01-26T21:50:59+00:00

In most cases we check the size of the bitmap file before reading data from it. However when reading the superblock, we always read the first PAGE_SIZE bytes, which might not always be appropriate. So limit that read to the size of the file if appropriate. Also, we get the count of available bytes wrong in one place, so that too can read past the end of the file. Cc: "yang yin" Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] struct path: convert md

2006-12-08T16:28:47+00:00

Signed-off-by: Josef Sipek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: endian annotations for the bitmap superblock

2006-10-21T20:35:05+00:00

And a couple of bug fixes found by sparse. Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: use BUILD_BUG_ON

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

Signed-off-by: Alexey Dobriyan Acked-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] md: use ffz instead of find_first_set to convert multiplier to shift

2006-10-03T15:04:18+00:00

find_first_set doesn't find the least-significant bit on bigendian machines, so it is really wrong to use it. ffs is closer, but takes an 'int' and we have a 'unsigned long'. So use ffz(~X) to convert a chunksize into a chunkshift. Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds