user/sven/linux.git, branch v2.6.30.7

Linux 2.6.30.7

2009-09-15T17:46:05Z

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

sound: oxygen: fix MCLK rate for 192 kHz playback

2009-09-15T17:45:30Z

commit b91ab72b830e1494c2c7f8de05ccb2ab2c9cfb26 upstream. Do not forget to program the MCLK ratio for the I2S output. Otherwise, the master clock frequency can be too high for the DACs at sample frequencies above 96 kHz. Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

sound: oxygen: handle cards with missing EEPROM

2009-09-15T17:45:29Z

commit 92653453c3015c083b9fe0ad48261c6b2267d482 upstream. The card model detection code introduced in 2.6.30 that tries to work around partially broken EEPROM contents by reading the EEPROM directly does not handle cards where the EEPROM has been omitted. In this case, we have to use the default ID to allow the driver to load. Signed-off-by: Clemens Ladisch Reported-and-tested-by: Ozan Çağlayan Signed-off-by: Takashi Iwai 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