kernel/linux.git/drivers, branch v3.0.52

intel-iommu: Fix AB-BA lockdep report

2012-11-17T21:14:26+00:00

commit 3e7abe2556b583e87dabda3e0e6178a67b20d06f upstream. When unbinding a device so that I could pass it through to a KVM VM, I got the lockdep report below. It looks like a legitimate lock ordering problem: - domain_context_mapping_one() takes iommu->lock and calls iommu_support_dev_iotlb(), which takes device_domain_lock (inside iommu->lock). - domain_remove_one_dev_info() starts by taking device_domain_lock then takes iommu->lock inside it (near the end of the function). So this is the classic AB-BA deadlock. It looks like a safe fix is to simply release device_domain_lock a bit earlier, since as far as I can tell, it doesn't protect any of the stuff accessed at the end of domain_remove_one_dev_info() anyway. BTW, the use of device_domain_lock looks a bit unsafe to me... it's at least not obvious to me why we aren't vulnerable to the race below: iommu_support_dev_iotlb() domain_remove_dev_info() lock device_domain_lock find info unlock device_domain_lock lock device_domain_lock find same info unlock device_domain_lock free_devinfo_mem(info) do stuff with info after it's free However I don't understand the locking here well enough to know if this is a real problem, let alone what the best fix is. Anyway here's the full lockdep output that prompted all of this: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.39.1+ #1 ------------------------------------------------------- bash/13954 is trying to acquire lock: (&(&iommu->lock)->rlock){......}, at: [] domain_remove_one_dev_info+0x121/0x230 but task is already holding lock: (device_domain_lock){-.-...}, at: [] domain_remove_one_dev_info+0x208/0x230 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (device_domain_lock){-.-...}: [] lock_acquire+0x9d/0x130 [] _raw_spin_lock_irqsave+0x55/0xa0 [] domain_context_mapping_one+0x600/0x750 [] domain_context_mapping+0x3f/0x120 [] iommu_prepare_identity_map+0x1c5/0x1e0 [] intel_iommu_init+0x88e/0xb5e [] pci_iommu_init+0x16/0x41 [] do_one_initcall+0x45/0x190 [] kernel_init+0xe3/0x168 [] kernel_thread_helper+0x4/0x10 -> #0 (&(&iommu->lock)->rlock){......}: [] __lock_acquire+0x195e/0x1e10 [] lock_acquire+0x9d/0x130 [] _raw_spin_lock_irqsave+0x55/0xa0 [] domain_remove_one_dev_info+0x121/0x230 [] device_notifier+0x72/0x90 [] notifier_call_chain+0x8c/0xc0 [] __blocking_notifier_call_chain+0x78/0xb0 [] blocking_notifier_call_chain+0x16/0x20 [] __device_release_driver+0xbc/0xe0 [] device_release_driver+0x2f/0x50 [] driver_unbind+0xa3/0xc0 [] drv_attr_store+0x2c/0x30 [] sysfs_write_file+0xe6/0x170 [] vfs_write+0xce/0x190 [] sys_write+0x54/0xa0 [] system_call_fastpath+0x16/0x1b other info that might help us debug this: 6 locks held by bash/13954: #0: (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x44/0x170 #1: (s_active#3){++++.+}, at: [] sysfs_write_file+0xcd/0x170 #2: (&__lockdep_no_validate__){+.+.+.}, at: [] driver_unbind+0x9b/0xc0 #3: (&__lockdep_no_validate__){+.+.+.}, at: [] device_release_driver+0x27/0x50 #4: (&(&priv->bus_notifier)->rwsem){.+.+.+}, at: [] __blocking_notifier_call_chain+0x5f/0xb0 #5: (device_domain_lock){-.-...}, at: [] domain_remove_one_dev_info+0x208/0x230 stack backtrace: Pid: 13954, comm: bash Not tainted 2.6.39.1+ #1 Call Trace: [] print_circular_bug+0xf7/0x100 [] __lock_acquire+0x195e/0x1e10 [] ? trace_hardirqs_off+0xd/0x10 [] ? trace_hardirqs_on_caller+0x13d/0x180 [] lock_acquire+0x9d/0x130 [] ? domain_remove_one_dev_info+0x121/0x230 [] _raw_spin_lock_irqsave+0x55/0xa0 [] ? domain_remove_one_dev_info+0x121/0x230 [] ? trace_hardirqs_off+0xd/0x10 [] domain_remove_one_dev_info+0x121/0x230 [] device_notifier+0x72/0x90 [] notifier_call_chain+0x8c/0xc0 [] __blocking_notifier_call_chain+0x78/0xb0 [] blocking_notifier_call_chain+0x16/0x20 [] __device_release_driver+0xbc/0xe0 [] device_release_driver+0x2f/0x50 [] driver_unbind+0xa3/0xc0 [] drv_attr_store+0x2c/0x30 [] sysfs_write_file+0xe6/0x170 [] vfs_write+0xce/0x190 [] sys_write+0x54/0xa0 [] system_call_fastpath+0x16/0x1b Signed-off-by: Roland Dreier Signed-off-by: David Woodhouse Cc: Steven Rostedt Signed-off-by: Greg Kroah-Hartman

USB: mos7840: remove unused variable

2012-11-17T21:14:25+00:00

Fix warning about unused variable introduced by commit e681b66f2e19fa ("USB: mos7840: remove invalid disconnect handling") upstream. A subsequent fix which removed the disconnect function got rid of the warning but that one was only backported to v3.6. Reported-by: Jiri Slaby Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

drm/i915: clear the entire sdvo infoframe buffer

2012-11-17T21:14:25+00:00

commit b6e0e543f75729f207b9c72b0162ae61170635b2 upstream. Like in the case of native hdmi, which is fixed already in commit adf00b26d18e1b3570451296e03bcb20e4798cdd Author: Paulo Zanoni Date: Tue Sep 25 13:23:34 2012 -0300 drm/i915: make sure we write all the DIP data bytes we need to clear the entire sdvo buffer to avoid upsetting the display. Since infoframe buffer writing is now a bit more elaborate, extract it into it's own function. This will be useful if we ever get around to properly update the ELD for sdvo. Also #define proper names for the two buffer indexes with fixed usage. v2: Cite the right commit above, spotted by Paulo Zanoni. v3: I'm too stupid to paste the right commit. v4: Ben Hutchings noticed that I've failed to handle an underflow in my loop logic, breaking it for i >= length + 8. Since I've just lost C programmer license, use his solution. Also, make the frustrated 0-base buffer size a notch more clear. Reported-and-tested-by: Jürg Billeter Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 Cc: Paulo Zanoni Cc: Ben Hutchings Reviewed-by: Rodrigo Vivi Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: fixup infoframe support for sdvo

2012-11-17T21:14:25+00:00

commit 81014b9d0b55fb0b48f26cd2a943359750d532db upstream. At least the worst offenders: - SDVO specifies that the encoder should compute the ecc. Testing also shows that we must not send the ecc field, so copy the dip_infoframe struct to a temporay place and avoid the ecc field. This way the avi infoframe is exactly 17 bytes long, which agrees with what the spec mandates as a minimal storage capacity (with the ecc field it would be 18 bytes). - Only 17 when sending the avi infoframe. The SDVO spec explicitly says that sending more data than what the device announces results in undefined behaviour. - Add __attribute__((packed)) to the avi and spd infoframes, for otherwise they're wrongly aligned. Noticed because the avi infoframe ended up being 18 bytes large instead of 17. We haven't noticed this yet because we don't use the uint16_t fields yet (which are the only ones that would be wrongly aligned). This regression has been introduce by 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 is the first bad commit commit 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 Author: David Härdeman Date: Fri Sep 24 21:44:32 2010 +0200 i915: enable AVI infoframe for intel_hdmi.c [v4] Patch tested on my g33 with a sdvo hdmi adaptor. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 Tested-by: Peter Ross (G35 SDVO-HDMI) Reviewed-by: Eugeni Dodonov Signed-Off-by: Daniel Vetter Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Fix hibernation device reset

2012-11-17T21:14:25+00:00

commit 95e8f6a21996c4cc2c4574b231c6e858b749dce3 upstream. The device would not reset properly when resuming from hibernation. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul Reviewed-by: Dmitry Torokhov Cc: linux-graphics-maintainer@vmware.com Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

net: usb: Fix memory leak on Tx data path

2012-11-17T21:14:24+00:00

[ Upstream commit 39707c2a3ba5011038b363f84d37c8a98d2d9db1 ] Driver anchors the tx urbs and defers the urb submission if a transmit request comes when the interface is suspended. Anchoring urb increments the urb reference count. These deferred urbs are later accessed by calling usb_get_from_anchor() for submission during interface resume. usb_get_from_anchor() unanchors the urb but urb reference count remains same. This causes the urb reference count to remain non-zero after usb_free_urb() gets called and urb never gets freed. Hence call usb_put_urb() after anchoring the urb to properly balance the reference count for these deferred urbs. Also, unanchor these deferred urbs during disconnect, to free them up. Signed-off-by: Hemant Kumar Acked-by: Oliver Neukum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

hwmon: (w83627ehf) Force initial bank selection

2012-11-17T21:14:22+00:00

commit 3300fb4f88688029fff8dfb9ec0734f6e4cba3e7 upstream. Don't assume bank 0 is selected at device probe time. This may not be the case. Force bank selection at first register access to guarantee that we read the right registers upon driver loading. Signed-off-by: Jean Delvare Reviewed-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

drm: restore open_count if drm_setup fails

2012-11-17T21:14:22+00:00

commit 0f1cb1bd94a9c967cd4ad3de51cfdabe61eb5dcc upstream. If drm_setup (called at first open) fails, the whole open call has failed, so we should not keep the open_count incremented. Signed-off-by: Ilija Hadzic Reviewed-by: Thomas Hellstrom Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

DRM/Radeon: Fix Load Detection on legacy primary DAC.

2012-11-17T21:14:20+00:00

commit 83325d072185899b706de2956170b246585aaec9 upstream. An uninitialized variable led to broken load detection. Signed-off-by: Egbert Eich Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

target: Don't return success from module_init() if setup fails

2012-11-17T21:14:20+00:00

commit 0d0f9dfb31e0a6c92063e235417b42df185b3275 upstream. If the call to core_dev_release_virtual_lun0() fails, then nothing sets ret to anything other than 0, so even though everything is torn down and freed, target_core_init_configfs() will seem to succeed and the module will be loaded. Fix this by passing the return value on up the chain. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman