linux/drivers, branch v2.6.30.7

dm snapshot: fix on disk chunk size validation

2009-09-15T17:45:36Z

commit ae0b7448e91353ea5f821601a055aca6b58042cd upstream. Fix some problems seen in the chunk size processing when activating a pre-existing snapshot. For a new snapshot, the chunk size can either be supplied by the creator or a default value can be used. For an existing snapshot, the chunk size in the snapshot header on disk should always be used. If someone attempts to load an existing snapshot and has the 'default chunk size' option set, the kernel uses its default value even when it is incorrect for the snapshot being loaded. This patch ensures the correct on-disk value is always used. Secondly, when the code does use the chunk size stored on the disk it is prudent to revalidate it, so the code can exit cleanly if it got corrupted as happened in https://bugzilla.redhat.com/show_bug.cgi?id=461506 . Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

dm exception store: split set_chunk_size

2009-09-15T17:45:35Z

commit 2defcc3fb4661e7351cb2ac48d843efc4c64db13 upstream. Break the function set_chunk_size to two functions in preparation for the fix in the following patch. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

dm snapshot: fix header corruption race on invalidation

2009-09-15T17:45:34Z

commit 61578dcd3fafe6babd72e8db32110cc0b630a432 upstream. If a persistent snapshot fills up, a race can corrupt the on-disk header which causes a crash on any future attempt to activate the snapshot (typically while booting). This patch fixes the race. When the snapshot overflows, __invalidate_snapshot is called, which calls snapshot store method drop_snapshot. It goes to persistent_drop_snapshot that calls write_header. write_header constructs the new header in the "area" location. Concurrently, an existing kcopyd job may finish, call copy_callback and commit_exception method, that goes to persistent_commit_exception. persistent_commit_exception doesn't do locking, relying on the fact that callbacks are single-threaded, but it can race with snapshot invalidation and overwrite the header that is just being written while the snapshot is being invalidated. The result of this race is a corrupted header being written that can lead to a crash on further reactivation (if chunk_size is zero in the corrupted header). The fix is to use separate memory areas for each. See the bug: https://bugzilla.redhat.com/show_bug.cgi?id=461506 Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

dm snapshot: refactor zero_disk_area to use chunk_io

2009-09-15T17:45:33Z

commit 02d2fd31defce6ff77146ad0fef4f19006055d86 upstream. Refactor chunk_io to prepare for the fix in the following patch. Pass an area pointer to chunk_io and simplify zero_disk_area to use chunk_io. No functional change. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

dm raid1: do not allow log_failure variable to unset after being set

2009-09-15T17:45:32Z

commit d2b698644c97cb033261536a4f2010924a00eac9 upstream. This patch fixes a bug which was triggering a case where the primary leg could not be changed on failure even when the mirror was in-sync. The case involves the failure of the primary device along with the transient failure of the log device. The problem is that bios can be put on the 'failures' list (due to log failure) before 'fail_mirror' is called due to the primary device failure. Normally, this is fine, but if the log device failure is transient, a subsequent iteration of the work thread, 'do_mirror', will reset 'log_failure'. The 'do_failures' function then resets the 'in_sync' variable when processing bios on the failures list. The 'in_sync' variable is what is used to determine if the primary device can be switched in the event of a failure. Since this has been reset, the primary device is incorrectly assumed to be not switchable. The case has been seen in the cluster mirror context, where one machine realizes the log device is dead before the other machines. As the responsibilities of the server migrate from one node to another (because the mirror is being reconfigured due to the failure), the new server may think for a moment that the log device is fine - thus resetting the 'log_failure' variable. In any case, it is inappropiate for us to reset the 'log_failure' variable. The above bug simply illustrates that it can actually hurt us. Signed-off-by: Jonathan Brassow Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

SCSI: sd: fix bug in SCSI async probing

2009-09-15T17:45:28Z

commit 601e7638254c118fca135af9b1a9f35061420f62 upstream. The async split up of probing in sd.c created a potential failure case where something goes wrong with device_add(), but which we don't recover properly. Since, in general, asynchronous error handling is hard, move the device_add() into the asynchronous path (it should be fast) and make sure all the deferred processing cannot fail. Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

PCI SR-IOV: correct broken resource alignment calculations

2009-09-15T17:45:27Z

commit 6faf17f6f1ffc586d16efc2f9fa2083a7785ee74 upstream. An SR-IOV capable device includes an SR-IOV PCIe capability which describes the Virtual Function (VF) BAR requirements. A typical SR-IOV device can support multiple VFs whose BARs must be in a contiguous region, effectively an array of VF BARs. The BAR reports the size requirement for a single VF. We calculate the full range needed by simply multiplying the VF BAR size with the number of possible VFs and create a resource spanning the full range. This all seems sane enough except it artificially inflates the alignment requirement for the VF BAR. The VF BAR need only be aligned to the size of a single BAR not the contiguous range of VF BARs. This can cause us to fail to allocate resources for the BAR despite the fact that we actually have enough space. This patch adds a thin PCI specific layer over the generic resource_alignment() function which is aware of the special nature of VF BARs and does sorting and allocation based on the smaller alignment requirement. I recognize that while resource_alignment is generic, it's basically a PCI helper. An alternative to this patch is to add PCI VF BAR specific information to struct resource. I opted for the extra layer rather than adding such PCI specific information to struct resource. This does have the slight downside that we don't cache the BAR size and re-read for each alignment query (happens a small handful of times during boot for each VF BAR). Signed-off-by: Chris Wright Cc: Ivan Kokshaysky Cc: Linus Torvalds Cc: Matthew Wilcox Cc: Yu Zhao Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

pppol2tp: calls unregister_pernet_gen_device() at unload time

2009-09-15T17:45:14Z

[ Upstream commit 446e72f30eca76d6f9a1a54adf84d2c6ba2831f8 ] Failure to call unregister_pernet_gen_device() can exhaust memory if module is loaded/unloaded many times. Signed-off-by: Eric Dumazet Acked-by: Cyrill Gorcunov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ppp: fix lost fragments in ppp_mp_explode() (resubmit)

2009-09-15T17:45:13Z

[ Upstream commit a53a8b56827cc429c6d9f861ad558beeb5f6103f ] This patch fixes the corner cases where the sum of MTU of the free channels (adjusted for fragmentation overheads) is less than the MTU of PPP link. There are at least 3 situations where this case might arise: - some of the channels are busy - the multilink session is running in a degraded state (i.e. with less than its full complement of active channels) - by design, where multilink protocol is being used to artificially increase the effective link MTU of a single link. Without this patch, at most 1 fragment is ever sent per free channel for a given PPP frame and any remaining part of the PPP frame that does not fit into those fragments is silently discarded. This patch restores the original behaviour which was broken by commit 9c705260feea6ae329bc6b6d5f6d2ef0227eda0a 'ppp:ppp_mp_explode() redesign'. Once all 'free' channels have been given a fragment, an additional fragment is queued to each available channel in turn, as many times as necessary, until the entire PPP frame has been consumed. Signed-off-by: Ben McKeegan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

E100: fix interaction with swiotlb on X86.

2009-09-15T17:45:10Z

[ Upstream commit 6ff9c2e7fa8ca63a575792534b63c5092099c286 ] E100 places it's RX packet descriptors inside skb->data and uses them with bidirectional streaming DMA mapping. Data in descriptors is accessed simultaneously by the chip (writing status and size when a packet is received) and CPU (reading to check if the packet was received). This isn't a valid usage of PCI DMA API, which requires use of the coherent (consistent) memory for such purpose. Unfortunately e100 chips working in "simplified" RX mode have to store received data directly after the descriptor. Fixing the driver to conform to the API would require using unsupported "flexible" RX mode or receiving data into a coherent memory and using CPU to copy it to network buffers. This patch, while not yet making the driver conform to the PCI DMA API, allows it to work correctly on X86 with swiotlb (while not breaking other architectures). Signed-off-by: Krzysztof Hałasa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman