summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* drm/radeon/kms: do bounds checking for 3D_LOAD_VBPNTR and bump array limitMarek Olšák2011-06-231-1/+7
| | | | | | | | | | | | | | | | | | commit a27bb4b209dd6c327fa4e7185f2487f9508a58db upstream. To my knowledge, the limit is 16 on r300. (the docs don't say what the limit is) The lack of bounds checking can be abused to do all sorts of things (from bypassing parts of the CS checker to crashing the kernel). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36745 Signed-off-by: Marek Olšák <maraeo@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* oprofile, dcookies: Fix possible circular locking dependencyRobert Richter2011-06-231-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit fe47ae7f53e179d2ef6771024feb000cbb86640f upstream. The lockdep warning below detects a possible A->B/B->A locking dependency of mm->mmap_sem and dcookie_mutex. The order in sync_buffer() is mm->mmap_sem/dcookie_mutex, while in sys_lookup_dcookie() it is vice versa. Fixing it in sys_lookup_dcookie() by unlocking dcookie_mutex before copy_to_user(). oprofiled/4432 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [<ffffffff810b444b>] might_fault+0x53/0xa3 but task is already holding lock: (dcookie_mutex){+.+.+.}, at: [<ffffffff81124d28>] sys_lookup_dcookie+0x45/0x149 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (dcookie_mutex){+.+.+.}: [<ffffffff8106557f>] lock_acquire+0xf8/0x11e [<ffffffff814634f0>] mutex_lock_nested+0x63/0x309 [<ffffffff81124e5c>] get_dcookie+0x30/0x144 [<ffffffffa0000fba>] sync_buffer+0x196/0x3ec [oprofile] [<ffffffffa0001226>] task_exit_notify+0x16/0x1a [oprofile] [<ffffffff81467b96>] notifier_call_chain+0x37/0x63 [<ffffffff8105803d>] __blocking_notifier_call_chain+0x50/0x67 [<ffffffff81058068>] blocking_notifier_call_chain+0x14/0x16 [<ffffffff8105a718>] profile_task_exit+0x1a/0x1c [<ffffffff81039e8f>] do_exit+0x2a/0x6fc [<ffffffff8103a5e4>] do_group_exit+0x83/0xae [<ffffffff8103a626>] sys_exit_group+0x17/0x1b [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b -> #0 (&mm->mmap_sem){++++++}: [<ffffffff81064dfb>] __lock_acquire+0x1085/0x1711 [<ffffffff8106557f>] lock_acquire+0xf8/0x11e [<ffffffff810b4478>] might_fault+0x80/0xa3 [<ffffffff81124de7>] sys_lookup_dcookie+0x104/0x149 [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b other info that might help us debug this: 1 lock held by oprofiled/4432: #0: (dcookie_mutex){+.+.+.}, at: [<ffffffff81124d28>] sys_lookup_dcookie+0x45/0x149 stack backtrace: Pid: 4432, comm: oprofiled Not tainted 2.6.39-00008-ge5a450d #9 Call Trace: [<ffffffff81063193>] print_circular_bug+0xae/0xbc [<ffffffff81064dfb>] __lock_acquire+0x1085/0x1711 [<ffffffff8102ef13>] ? get_parent_ip+0x11/0x42 [<ffffffff810b444b>] ? might_fault+0x53/0xa3 [<ffffffff8106557f>] lock_acquire+0xf8/0x11e [<ffffffff810b444b>] ? might_fault+0x53/0xa3 [<ffffffff810d7d54>] ? path_put+0x22/0x27 [<ffffffff810b4478>] might_fault+0x80/0xa3 [<ffffffff810b444b>] ? might_fault+0x53/0xa3 [<ffffffff81124de7>] sys_lookup_dcookie+0x104/0x149 [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b References: https://bugzilla.kernel.org/show_bug.cgi?id=13809 Signed-off-by: Robert Richter <robert.richter@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* oprofile: Fix locking dependency in sync_start()Robert Richter2011-06-231-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 130c5ce716c9bfd1c2a2ec840a746eb7ff9ce1e6 upstream. This fixes the A->B/B->A locking dependency, see the warning below. The function task_exit_notify() is called with (task_exit_notifier) .rwsem set and then calls sync_buffer() which locks buffer_mutex. In sync_start() the buffer_mutex was set to prevent notifier functions to be started before sync_start() is finished. But when registering the notifier, (task_exit_notifier).rwsem is locked too, but now in different order than in sync_buffer(). In theory this causes a locking dependency, what does not occur in practice since task_exit_notify() is always called after the notifier is registered which means the lock is already released. However, after checking the notifier functions it turned out the buffer_mutex in sync_start() is unnecessary. This is because sync_buffer() may be called from the notifiers even if sync_start() did not finish yet, the buffers are already allocated but empty. No need to protect this with the mutex. So we fix this theoretical locking dependency by removing buffer_mutex in sync_start(). This is similar to the implementation before commit: 750d857 oprofile: fix crash when accessing freed task structs which introduced the locking dependency. Lockdep warning: oprofiled/4447 is trying to acquire lock: (buffer_mutex){+.+...}, at: [<ffffffffa0000e55>] sync_buffer+0x31/0x3ec [oprofile] but task is already holding lock: ((task_exit_notifier).rwsem){++++..}, at: [<ffffffff81058026>] __blocking_notifier_call_chain+0x39/0x67 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 ((task_exit_notifier).rwsem){++++..}: [<ffffffff8106557f>] lock_acquire+0xf8/0x11e [<ffffffff81463a2b>] down_write+0x44/0x67 [<ffffffff810581c0>] blocking_notifier_chain_register+0x52/0x8b [<ffffffff8105a6ac>] profile_event_register+0x2d/0x2f [<ffffffffa00013c1>] sync_start+0x47/0xc6 [oprofile] [<ffffffffa00001bb>] oprofile_setup+0x60/0xa5 [oprofile] [<ffffffffa00014e3>] event_buffer_open+0x59/0x8c [oprofile] [<ffffffff810cd3b9>] __dentry_open+0x1eb/0x308 [<ffffffff810cd59d>] nameidata_to_filp+0x60/0x67 [<ffffffff810daad6>] do_last+0x5be/0x6b2 [<ffffffff810dbc33>] path_openat+0xc7/0x360 [<ffffffff810dbfc5>] do_filp_open+0x3d/0x8c [<ffffffff810ccfd2>] do_sys_open+0x110/0x1a9 [<ffffffff810cd09e>] sys_open+0x20/0x22 [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b -> #0 (buffer_mutex){+.+...}: [<ffffffff81064dfb>] __lock_acquire+0x1085/0x1711 [<ffffffff8106557f>] lock_acquire+0xf8/0x11e [<ffffffff814634f0>] mutex_lock_nested+0x63/0x309 [<ffffffffa0000e55>] sync_buffer+0x31/0x3ec [oprofile] [<ffffffffa0001226>] task_exit_notify+0x16/0x1a [oprofile] [<ffffffff81467b96>] notifier_call_chain+0x37/0x63 [<ffffffff8105803d>] __blocking_notifier_call_chain+0x50/0x67 [<ffffffff81058068>] blocking_notifier_call_chain+0x14/0x16 [<ffffffff8105a718>] profile_task_exit+0x1a/0x1c [<ffffffff81039e8f>] do_exit+0x2a/0x6fc [<ffffffff8103a5e4>] do_group_exit+0x83/0xae [<ffffffff8103a626>] sys_exit_group+0x17/0x1b [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b other info that might help us debug this: 1 lock held by oprofiled/4447: #0: ((task_exit_notifier).rwsem){++++..}, at: [<ffffffff81058026>] __blocking_notifier_call_chain+0x39/0x67 stack backtrace: Pid: 4447, comm: oprofiled Not tainted 2.6.39-00007-gcf4d8d4 #10 Call Trace: [<ffffffff81063193>] print_circular_bug+0xae/0xbc [<ffffffff81064dfb>] __lock_acquire+0x1085/0x1711 [<ffffffffa0000e55>] ? sync_buffer+0x31/0x3ec [oprofile] [<ffffffff8106557f>] lock_acquire+0xf8/0x11e [<ffffffffa0000e55>] ? sync_buffer+0x31/0x3ec [oprofile] [<ffffffff81062627>] ? mark_lock+0x42f/0x552 [<ffffffffa0000e55>] ? sync_buffer+0x31/0x3ec [oprofile] [<ffffffff814634f0>] mutex_lock_nested+0x63/0x309 [<ffffffffa0000e55>] ? sync_buffer+0x31/0x3ec [oprofile] [<ffffffffa0000e55>] sync_buffer+0x31/0x3ec [oprofile] [<ffffffff81058026>] ? __blocking_notifier_call_chain+0x39/0x67 [<ffffffff81058026>] ? __blocking_notifier_call_chain+0x39/0x67 [<ffffffffa0001226>] task_exit_notify+0x16/0x1a [oprofile] [<ffffffff81467b96>] notifier_call_chain+0x37/0x63 [<ffffffff8105803d>] __blocking_notifier_call_chain+0x50/0x67 [<ffffffff81058068>] blocking_notifier_call_chain+0x14/0x16 [<ffffffff8105a718>] profile_task_exit+0x1a/0x1c [<ffffffff81039e8f>] do_exit+0x2a/0x6fc [<ffffffff81465031>] ? retint_swapgs+0xe/0x13 [<ffffffff8103a5e4>] do_group_exit+0x83/0xae [<ffffffff8103a626>] sys_exit_group+0x17/0x1b [<ffffffff8146ad4b>] system_call_fastpath+0x16/0x1b Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Carl Love <carll@us.ibm.com> Signed-off-by: Robert Richter <robert.richter@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* oprofile: Free potentially owned tasks in case of errorsRobert Richter2011-06-231-4/+9
| | | | | | | | | | | | commit 6ac6519b93065625119a347be1cbcc1b89edb773 upstream. After registering the task free notifier we possibly have tasks in our dying_tasks list. Free them after unregistering the notifier in case of an error. Signed-off-by: Robert Richter <robert.richter@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ALSA: hda: Fix quirk for Dell Inspiron 910Daniel T Chen2011-06-231-0/+1
| | | | | | | | | | | | | | | | | | commit 0a1896b27b030529ec770aefd790544a1bdb7d5a upstream. BugLink: https://launchpad.net/bugs/792712 The original reporter states that sound from the internal speakers is inaudible until using the model=auto quirk. This symptom is due to an existing quirk mask for 0x102802b* that uses the model=dell quirk. To limit the possible regressions, leave the existing quirk mask but add a higher priority specific mask for the reporter's PCI SSID. Reported-and-tested-by: rodni hipp Signed-off-by: Daniel T Chen <crimsun@ubuntu.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ASoC: SAMSUNG: Fix the incorrect referencing of I2SCON registerSangbeom Kim2011-06-231-2/+2
| | | | | | | | | | | | | | | commit 33195500edf260e8c8809ab9dfc67f50e0ce031f upstream. If DMA active status should be checked, I2SCON register should be referenced. In this patch, Fix the incorrect referencing of I2SCON register. Reported-by : Lakkyung Jung <lakkyung.jung@samsung.com> Signed-off-by: Sangbeom Kim <sbkim73@samsung.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ASoC: snd_soc_new_{mixer,mux,pga} make sure to use right DAPM contextLars-Peter Clausen2011-06-231-9/+8
| | | | | | | | | | | | | | | commit 4b80b8c2eee5282dab57f094fd3893c0c09f750c upstream. Currently it is possible that snd_soc_new_{mixer,mux,pga} is called with a DAPM context not matching the widgets context. This can lead to a wrong prefix_len calculation, which will result in undefined behaviour. To avoid this always use the DAPM context from the widget itself. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ASoC: WM8804 does not support sample rates below 32kHzMark Brown2011-06-231-2/+7
| | | | | | | | | | commit 3115ae174620eeab4b16f52c8d0a9a35d2717e3c upstream. Reported-by: Kieran O'Leary <Kieran.O'Leary@wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ASoC: Fix WM8962 headphone volume update for use of advanced cachesMark Brown2011-06-231-2/+2
| | | | | | | | | commit 0f82bdf572fc6e42147151aa4d52542f7fc6d793 upstream. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ASoC: AD1836: Fix setting the PCM formatLars-Peter Clausen2011-06-232-7/+13
| | | | | | | | | | commit 8ca695f273709a9d147826716a8dee3e0eb2407f upstream. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* cifs: don't allow cifs_reconnect to exit with NULL socket pointerJeff Layton2011-06-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 7fdbaa1b8daa1009b705985b903e3d2ebccad456 upstream. It's possible for the following set of events to happen: cifsd calls cifs_reconnect which reconnects the socket. A userspace process then calls cifs_negotiate_protocol to handle the NEGOTIATE and gets a reply. But, while processing the reply, cifsd calls cifs_reconnect again. Eventually the GlobalMid_Lock is dropped and the reply from the earlier NEGOTIATE completes and the tcpStatus is set to CifsGood. cifs_reconnect then goes through and closes the socket and sets the pointer to zero, but because the status is now CifsGood, the new socket is not created and cifs_reconnect exits with the socket pointer set to NULL. Fix this by only setting the tcpStatus to CifsGood if the tcpStatus is CifsNeedNegotiate, and by making sure that generic_ip_connect is always called at least once in cifs_reconnect. Note that this is not a perfect fix for this issue. It's still possible that the NEGOTIATE reply is handled after the socket has been closed and reconnected. In that case, the socket state will look correct but it no NEGOTIATE was performed on it be for the wrong socket. In that situation though the server should just shut down the socket on the next attempted send, rather than causing the oops that occurs today. Reported-and-Tested-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* AppArmor: Fix sleep in invalid context from task_setrlimitJohn Johansen2011-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 1780f2d3839a0d3eb85ee014a708f9e2c8f8ba0e upstream. Affected kernels 2.6.36 - 3.0 AppArmor may do a GFP_KERNEL memory allocation with task_lock(tsk->group_leader); held when called from security_task_setrlimit. This will only occur when the task's current policy has been replaced, and the task's creds have not been updated before entering the LSM security_task_setrlimit() hook. BUG: sleeping function called from invalid context at mm/slub.c:847 in_atomic(): 1, irqs_disabled(): 0, pid: 1583, name: cupsd 2 locks held by cupsd/1583: #0: (tasklist_lock){.+.+.+}, at: [<ffffffff8104dafa>] do_prlimit+0x61/0x189 #1: (&(&p->alloc_lock)->rlock){+.+.+.}, at: [<ffffffff8104db2d>] do_prlimit+0x94/0x189 Pid: 1583, comm: cupsd Not tainted 3.0.0-rc2-git1 #7 Call Trace: [<ffffffff8102ebf2>] __might_sleep+0x10d/0x112 [<ffffffff810e6f46>] slab_pre_alloc_hook.isra.49+0x2d/0x33 [<ffffffff810e7bc4>] kmem_cache_alloc+0x22/0x132 [<ffffffff8105b6e6>] prepare_creds+0x35/0xe4 [<ffffffff811c0675>] aa_replace_current_profile+0x35/0xb2 [<ffffffff811c4d2d>] aa_current_profile+0x45/0x4c [<ffffffff811c4d4d>] apparmor_task_setrlimit+0x19/0x3a [<ffffffff811beaa5>] security_task_setrlimit+0x11/0x13 [<ffffffff8104db6b>] do_prlimit+0xd2/0x189 [<ffffffff8104dea9>] sys_setrlimit+0x3b/0x48 [<ffffffff814062bb>] system_call_fastpath+0x16/0x1b Signed-off-by: John Johansen <john.johansen@canonical.com> Reported-by: Miles Lane <miles.lane@gmail.com> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: xhci - fix interval calculation for FS isoc endpointsDmitry Torokhov2011-06-231-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | commit cd3c18ba2fac14b34d03cae111f215009735ea06 upstream. Full-speed isoc endpoints specify interval in exponent based form in frames, not microframes, so we need to adjust accordingly. NEC xHCI host controllers will return an error code of 0x11 if a full speed isochronous endpoint is added with the Interval field set to something less than 3 (2^3 = 8 microframes, or one frame). It is impossible for a full speed device to have an interval smaller than one frame. This was always an issue in the xHCI driver, but commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval()" removed the clamping of the minimum value in the Interval field, which revealed this bug. This needs to be backported to stable kernels back to 2.6.31. Reported-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xhci: Disable MSI for some Fresco Logic hosts.Sarah Sharp2011-06-233-2/+20
| | | | | | | | | | | | | | | | | | commit f5182b4155b9d686c5540a6822486400e34ddd98 upstream. Some Fresco Logic hosts, including those found in the AUAU N533V laptop, advertise MSI, but fail to actually generate MSI interrupts. Add a new xHCI quirk to skip MSI enabling for the Fresco Logic host controllers. Fresco Logic confirms that all chips with PCI vendor ID 0x1b73 and device ID 0x1000, regardless of PCI revision ID, do not support MSI. This should be backported to stable kernels as far back as 2.6.36, which was the first kernel to support MSI on xHCI hosts. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Sergey Galanov <sergey.e.galanov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xhci: Do not issue device reset when device is not setupMaarten Lankhorst2011-06-231-0/+7
| | | | | | | | | | | | | | | | | | | | commit 001fd3826f4c736ce292315782d015f768399080 upstream. xHCI controllers respond to a Reset Device command when the Slot is in the Enabled/Disabled state by returning an error. This is fine on other host controllers, but the Etron xHCI host controller returns a vendor-specific error code that the xHCI driver doesn't understand. The xHCI driver then gives up on device enumeration. Instead of issuing a command that will fail, just return. This fixes the issue with the xhci driver not working on ASRock P67 Pro/Extreme boards. This should be backported to stable kernels as far back as 2.6.34. Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xhci: Add defines for hardcoded slot statesMaarten Lankhorst2011-06-232-4/+9
| | | | | | | | | | | | commit e2b0217715c6d10379d94bdfe5560af96eecbb7c upstream. This needs to be added to the stable trees back to 2.6.34 to support an upcoming bug fix. Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Revert "x86, efi: Retain boot service code until after switching to virtual ↵Greg Kroah-Hartman2011-06-234-55/+3
| | | | | | | | | | | | | | | | | | | | | mode" This reverts commit 0aed459e8487eb6ebdb4efe8cefe1eafbc704b30, which was commit 916f676f8dc016103f983c7ec54c18ecdbb6e349 upstream. It breaks some people's machines, so this will all get worked out in the 3.0 kernel release, it's not quite ready for 2.6.39 just yet. Thanks to Maarten Lankhorst <m.b.lankhorst@gmail.com> for reporting the issue. Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com> Cc: Jim Bos <jim876@xs4all.nl> Cc: Matthew Garrett <mjg@redhat.com> Cc: H. Peter Anvin <hpa@linux.intel.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* usb-storage: redo incorrect readsAlan Stern2011-06-236-2/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 21c13a4f7bc185552c4b402b792c3bbb9aa69df0 upstream. Some USB mass-storage devices have bugs that cause them not to handle the first READ(10) command they receive correctly. The Corsair Padlock v2 returns completely bogus data for its first read (possibly it returns the data in encrypted form even though the device is supposed to be unlocked). The Feiya SD/SDHC card reader fails to complete the first READ(10) command after it is plugged in or after a new card is inserted, returning a status code that indicates it thinks the command was invalid, which prevents the kernel from retrying the read. Since the first read of a new device or a new medium is for the partition sector, the kernel is unable to retrieve the device's partition table. Users have to manually issue an "hdparm -z" or "blockdev --rereadpt" command before they can access the device. This patch (as1470) works around the problem. It adds a new quirk flag, US_FL_INVALID_READ10, indicating that the first READ(10) should always be retried immediately, as should any failing READ(10) commands (provided the preceding READ(10) command succeeded, to avoid getting stuck in a loop). The patch also adds appropriate unusual_devs entries containing the new flag. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Sven Geggus <sven-usbst@geggus.net> Tested-by: Paul Hartman <paul.hartman+linux@gmail.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: serial: add another 4N-GALAXY.DE PID to ftdi_sio driverSteffen Sledz2011-06-232-0/+2
| | | | | | | | | | commit a26d31cef06f43a76327c21235e75450869df2b8 upstream. E.g. newer CAN 2.0 A/B <=> USB 2.0 converters report idProduct=f3c2. Signed-off-by: Steffen Sledz <sledz@dresearch-fe.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: core: Tolerate protocol stall during hub and port status readLibor Pechacek2011-06-231-2/+4
| | | | | | | | | | | | | | commit 3824c1ddaf744be44b170a335332b9d6afe79254 upstream. Protocol stall should not be fatal while reading port or hub status as it is transient state. Currently hub EP0 STALL during port status read results in failed device enumeration. This has been observed with ST-Ericsson (formerly Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard. Signed-off-by: Libor Pechacek <lpechacek@suse.cz> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Revert "USB: option: add ID for ZTE MF 330"Greg Kroah-Hartman2011-06-231-5/+0
| | | | | | | | | | | | | | | | | | | | commit 3095ec895fd5ec19a7cb60b5cbfa766d68a74a24 upstream. This reverts commit a559d2c8c1bf652ea2d0ecd6ab4a250fcdb37db8. Turns out that device id 0x1d6b:0x0002 is a USB hub, which causes havoc when the option driver tries to bind to it. So revert this as it doesn't seem to be needed at all. Thanks to Michael Tokarev and Paweł Drobek for working on resolving this issue. Cc: Paweł Drobek <pawel.drobek@gmail.com> Cc: Michael Tokarev <mjt@tls.msk.ru> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: option Add blacklist for ZTE K3765-Z (19d2:2002)Torsten Hilbrich2011-06-231-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 7e8e62e4a5d26e4cb45f25dddd093837d75616c2 upstream. The funtion option_send_status times out when sending USB messages to the interfaces 0, 1, and 2 of this UMTS stick. This results in a 5s timeout in the function causing other tty operations to feel very sluggish. This patch adds a blacklist entry for these 3 interfaces on the ZTE K3765-Z device. I was also able to reproduce the problem with v2.6.38 and v2.6.39. This is very similar to a problem fixed in commit 7a89e4cb9cdaba92f5fbc509945cf4e3c48db4e2 Author: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Date: Wed Mar 9 09:19:48 2011 +0000 USB: serial: option: Apply OPTION_BLACKLIST_SENDSETUP also for ZTE MF626 Signed-off-by: Torsten Hilbrich <torsten.hilbrich@secunet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* option: add Prolink PH300 modem IDsDan Williams2011-06-231-0/+2
| | | | | | | | | | commit 5c3e4076ee8253c1e3688d10653ddee47a03b0db upstream. Simple ID addition. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* option: add Alcatel X200 to sendsetup blacklistDan Williams2011-06-231-2/+11
| | | | | | | | | | | | | | | | | | commit 15badbcc8eede58b0d7e53a3acde1c90a7b6e40e upstream. This modem really wants sendsetup blacklisted for interfaces 0 and 1, otherwise the kernel hardlocks for about 10 seconds while waiting for the modem's firmware to respond, which it of course doesn't do. A slight complication here is that TCT (who owns the Alcatel brand) used the same USB IDs for the X200 as the X060s despite the devices having completely different firmware and AT command sets, so we end up adding the X060s to the blacklist at the same time. PSA to OEMs: don't use the same USB IDs for different devices. Really. It makes your kittens cry. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* option: add Zoom 4597 modem USB IDsDan Williams2011-06-231-0/+4
| | | | | | | | | | commit cdacb598fe7ab85de80908c818dd7d66a2971117 upstream. Uses Longcheer-based firmware and AT command set. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* exec: delay address limit change until point of no returnMathias Krause2011-06-233-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | commit dac853ae89043f1b7752875300faf614de43c74b upstream. Unconditionally changing the address limit to USER_DS and not restoring it to its old value in the error path is wrong because it prevents us using kernel memory on repeated calls to this function. This, in fact, breaks the fallback of hard coded paths to the init program from being ever successful if the first candidate fails to load. With this patch applied switching to USER_DS is delayed until the point of no return is reached which makes it possible to have a multi-arch rootfs with one arch specific init binary for each of the (hard coded) probed paths. Since the address limit is already set to USER_DS when start_thread() will be invoked, this redundancy can be safely removed. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* staging: gma500: get control from firmware framebuffer if conflictsMichael Chang2011-06-231-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | commit aaa5c677910d313ca1318c905c799c459c6f0078 upstream. Many Linux distributions would enable vesafb in order to display early stage boot splash. In this case, we will get garbled X Window screen if running X fbdev on psbfb. This is because fb0 is occupied by vesafb while psbfb is on fb1. They tried to drive the same pieces of hardware at the same time. With unmodified X start-up, it would try to use default fb0 framebuffer device and unfortunately it is now broken becaues fb1 supersedes it. We should let psbfb takeover framebuffer control from vesafb to get around this problem. See also commit : 4410f3910947dcea8672280b3adecd53cec4e85e Signed-off-by: Michael Chang <mchang@novell.com> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: cdc-acm: Adding second ACM channel support for Nokia E7 and C7Toby Gray2011-06-231-0/+2
| | | | | | | | | | | | | commit 4061fde2fa80f40cb27114f60500d38d0afcf350 upstream. This adds the Nokia E7 and C7 to the list of devices in cdc-acm, allowing the secondary ACM channel on the device to be exposed. Without this patch the ACM driver won't claim this secondary channel as it's marked as having a vendor-specific protocol. Signed-off-by: Toby Gray <toby.gray@realvnc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* x86/amd-iommu: Fix boot crash with hidden PCI devicesJoerg Roedel2011-06-231-1/+21
| | | | | | | | | | | | | | | | | commit 26018874e3584f1658570d41d57d4c34f6a53aa0 upstream. Some PCIe cards ship with a PCI-PCIe bridge which is not visible as a PCI device in Linux. But the device-id of the bridge is present in the IOMMU tables which causes a boot crash in the IOMMU driver. This patch fixes by removing these cards from the IOMMU handling. This is a pure -stable fix, a real fix to handle this situation appriatly will follow for the next merge window. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* x86/amd-iommu: Fix 3 possible endless loopsJoerg Roedel2011-06-231-4/+4
| | | | | | | | | | | | | commit 0de66d5b35ee148455e268b2782873204ffdef4b upstream. The driver contains several loops counting on an u16 value where the exit-condition is checked against variables that can have values up to 0xffff. In this case the loops will never exit. This patch fixed 3 such loops. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* x86/amd-iommu: Use only per-device dma_opsJoerg Roedel2011-06-231-2/+24
| | | | | | | | | | | | | | commit 27c2127a15d340706c0aa84e311188a14468d841 upstream. Unfortunatly there are systems where the AMD IOMMU does not cover all devices. This breaks with the current driver as it initializes the global dma_ops variable. This patch limits the AMD IOMMU to the devices listed in the IVRS table fixing DMA for devices not covered by the IOMMU. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* media: Fix media device minor registrationLaurent Pinchart2011-06-231-2/+2
| | | | | | | | | | | | | | | | | commit 8c89ddd536bbe97c1e50424778a139abbf5763c3 upstream. The find_next_zero_bit() is called with the from and to arguments in the wrong order. This results in the function always returning 0, and all media devices being registered with minor 0. Furthermore, mdev->minor is then used before being assigned with the find_next_zero_bit() return value. This really makes sure we'll always use minor 0. Fix this and let the system support more than one media device. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* cifs: silence printk when establishing first session on socketJeff Layton2011-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | commit 9c4843ea576107a3c1fb94f2f758f198e9fe9e54 upstream. When signing is enabled, the first session that's established on a socket will cause a printk like this to pop: CIFS VFS: Unexpected SMB signature This is because the key exchange hasn't happened yet, so the signature field is bogus. Don't try to check the signature on the socket until the first session has been established. Also, eliminate the specific check for SMB_COM_NEGOTIATE since this check covers that case too. Cc: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* genirq: Fix descriptor init on non-sparse IRQsLinus Walleij2011-06-231-5/+3
| | | | | | | | | | | | | | | | | | | commit e7fbad300a7a6432238f086e3c9a61538a905858 upstream. The genirq changes are initializing descriptors for sparse IRQs quite differently from how non-sparse (stacked?) IRQs are initialized, with the effect that on my platform all IRQs are default-disabled on sparse IRQs and default-enabled if non-sparse IRQs are used, crashing some GPIO driver. Fix this by refactoring the non-sparse IRQs to use the same descriptor init function as the sparse IRQs. Signed-off: Linus Walleij <linus.walleij@linaro.org> Link: http://lkml.kernel.org/r/1306858479-16622-1-git-send-email-linus.walleij@stericsson.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* video: Fix use-after-free by vga16fb on rmmodBruno Prémont2011-06-231-0/+2
| | | | | | | | | | | | | | | | commit a50d28de8d5085e0f34f96088a45cc156d022021 upstream. Since fb_info is now refcounted and thus may get freed at any time it gets unregistered module unloading will try to unregister framebuffer as stored in platform data on probe though this pointer may be stale. Cleanup platform data on framebuffer release. Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* xen: off by one errors in multicalls.cDan Carpenter2011-06-231-6/+6
| | | | | | | | | | | | | | commit f124c6ae59e193705c9ddac57684d50006d710e6 upstream. b->args[] has MC_ARGS elements, so the comparison here should be ">=" instead of ">". Otherwise we read past the end of the array one space. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* fat: Fix corrupt inode flags when remove ATTR_SYS flagOGAWA Hirofumi2011-06-231-1/+1
| | | | | | | | | | | commit 1adffbae22332bb558c2a29de19d9aca391869f6 upstream. We are clearly missing '~' in fat_ioctl_set_attributes(). Reported-by: Dmitry Dmitriev <dimondmm@yandex.ru> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* drm/radeon/kms: fix for radeon on systems >4GB without hardware iommuDaniel Haid2011-06-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | commit 62fff811d73095bd95579d72f558f03c78f7914a upstream. On my x86_64 system with >4GB of ram and swiotlb instead of a hardware iommu (because I have a VIA chipset), the call to pci_set_dma_mask (see below) with 40bits returns an error. But it seems that the radeon driver is designed to have need_dma32 = true exactly if pci_set_dma_mask is called with 32 bits and false if it is called with 40 bits. I have read somewhere that the default are 32 bits. So if the call fails I suppose that need_dma32 should be set to true. And indeed the patch fixes the problem I have had before and which I had described here: http://choon.net/forum/read.php?21,106131,115940 Acked-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* drm/radeon/kms: viewport height has to be evenAlex Deucher2011-06-231-4/+8
| | | | | | | | | | | | | commit adcfde516e10aad72d66f6fefd36e6d0e6bd7be7 upstream. Otherwise, no vblank interrupts. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=37522 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* drm/i915: Add a no lvds quirk for the Asus EeeBox PC EB1007Hans de Goede2011-06-231-0/+8
| | | | | | | | | | | | | | commit 6a574b5b9b186e28abd3e571dfd1700c5220b510 upstream. I found this while figuring out why gnome-shell would not run on my Asus EeeBox PC EB1007. As a standalone "pc" this device cleary does not have an internal panel, yet it claims it does. Add a quirk to fix this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* lockdep: Fix lock_is_held() on recursionPeter Zijlstra2011-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | | commit f2513cde93f0957d5dc6c09bc24b0cccd27d8e1d upstream. The main lock_is_held() user is lockdep_assert_held(), avoid false assertions in lockdep_off() sections by unconditionally reporting the lock is taken. [ the reason this is important is a lockdep_assert_held() in ttwu() which triggers a warning under lockdep_off() as in printk() which can trigger another wakeup and lock up due to spinlock recursion, as reported and heroically debugged by Arne Jansen ] Reported-and-tested-by: Arne Jansen <lists@die-jansens.de> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1307398759.2497.966.camel@laptop Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* usbnet/cdc_ncm: add missing .reset_resume hookStefan Metzmacher2011-06-231-0/+1
| | | | | | | | | | | | | | | | | | | | | commit 85e3c65fa3a1d0542c181510a950a2be7733ff29 upstream. This avoids messages like this after suspend: cdc_ncm 2-1.4:1.6: no reset_resume for driver cdc_ncm? cdc_ncm 2-1.4:1.7: no reset_resume for driver cdc_ncm? cdc_ncm 2-1.4:1.6: usb0: unregister 'cdc_ncm' usb-0000:00:1d.0-1.4, CDC NCM This is important for the Ericsson F5521gw GSM/UMTS modem. Otherwise modemmanager looses the fact that the cdc_ncm and cdc_acm devices belong together. The cdc_ether module does the same. Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* block: export blk_{get,put}_queue()Jens Axboe2011-06-231-0/+2
| | | | | | | | | | | commit d86e0e83b32bc84600adb0b6ea1fce389b266682 upstream. We need them in SCSI to fix a bug, but currently they are not exported to modules. Export them. Signed-off-by: Jens Axboe <jaxboe@fusionio.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* nl80211: fix check for valid SSID size in scan operationsLuciano Coelho2011-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | commit 208c72f4fe44fe09577e7975ba0e7fa0278f3d03 upstream. In both trigger_scan and sched_scan operations, we were checking for the SSID length before assigning the value correctly. Since the memory was just kzalloc'ed, the check was always failing and SSID with over 32 characters were allowed to go through. This was causing a buffer overflow when copying the actual SSID to the proper place. This bug has been there since 2.6.29-rc4. Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* asus-wmi: Remove __init from asus_wmi_platform_initJoe Perches2011-06-231-1/+1
| | | | | | | | | | | | commit 39ddf3bf6463bc86041e806b43e014d50a144aa4 upstream. It's used by a non-init function. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* powerpc: Fix 32-bit SMP buildJosh Boyer2011-06-231-1/+1
| | | | | | | | | | | | | | | | | commit 6de06f313a65d0ecabf055e708d082002b568866 upstream. Commit 69e3cea8d5fd526 ("powerpc/smp: Make start_secondary_resume available to all CPU variants") introduced start_secondary_resume to misc_32.S, however it uses a 64-bit instruction which is not valid on 32-bit platforms. Use 'stw' instead. Reported-by: Richard Cochran <richardcochran@gmail.com> Tested-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: Set PCIE maxpayload for card during hotplug insertionJordan_Hargrave@Dell.com2011-06-231-0/+45
| | | | | | | | | | | | | | | | commit e522a7126c7c144a1dd14c6f217ac31e71082b1d upstream. The following patch sets the MaxPayload setting to match the parent reading when inserting a PCIE card into a hotplug slot. On our system, the upstream bridge is set to 256, but when inserting a card, the card setting defaults to 128. As soon as I/O is performed to the card it starts receiving errors since the payload size is too small. Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* serial: core, remove uart_update_termiosJiri Slaby2011-06-231-24/+1
| | | | | | | | | | | | | | | | | commit 6f5c24ad0f7619502199185a026a228174a27e68 upstream. Now, uart_update_termios is empty, so it's time to remove it. We no longer need a live tty in .dtr_rts. So this should prune all the bugs where tty is zeroed in port->tty during tty_port_block_til_ready. There is one thing to note. We don't set ASYNC_NORMAL_ACTIVE now. It's because this is done already in tty_port_block_til_ready. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* serial: core, do not set DTR/RTS twice on startupJiri Slaby2011-06-231-14/+0
| | | | | | | | | | | | | | | | | commit 303a7a1199c20f7c9452f024a6e17bf348b6b398 upstream. In .dtr_rts we do: uart_set_mctrl(uport, TIOCM_DTR | TIOCM_RTS) and call uart_update_termios. It does: uart_set_mctrl(port, TIOCM_DTR | TIOCM_RTS) once again. As the only callsite of uart_update_termios is .dtr_rts, remove the uart_set_mctrl from uart_update_termios to not set it twice. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* serial: core, move termios handling to uart_startupJiri Slaby2011-06-231-15/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c7d7abff40c27f82fe78b1091ab3fad69b2546f9 upstream. We should not fiddle with speed and cflags in .dtr_rts hook. Actually we might not have tty at that moment already. So move the console cflag copy and speed setup into uart_startup. Actually the speed setup is already there, but we need to call it unconditionally (uart_startup is called from uart_open with hw_init = 0). This means we move uart_change_speed before dtr/rts setup in .dtr_rts. But this should not matter as the setup should be called after uart_change_speed anyway. Before: After: dtr/rts setup (dtr_rts) uart_change_speed (startup) uart_change_speed (update_termios) dtr/rts setup (dtr_rts) dtr/rts setup (update_termios) dtr/rts setup (update_termios) The second setup will dismiss with the next patch. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.25.1) at 2025-03-31 15:45:14 +0000