| Age | Commit message (Collapse) | Author |
|---|
|
commit 4e54d93d3c9846ba1c2644ad06463dafa690d1b7 upstream.
When running following code in a machine which has VIVT caches and
USE_SPLIT_PTLOCKS is not defined:
fd = open("/etc/passwd", O_RDONLY);
addr = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, 0);
addr2 = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd, 0);
v = *((int *)addr);
we will hang in spinlock recursion in the page fault handler:
BUG: spinlock recursion on CPU#0, mmap_test/717
lock: c5e295d8, .magic: dead4ead, .owner: mmap_test/717,
.owner_cpu: 0
[<c0026604>] (unwind_backtrace+0x0/0xec)
[<c014ee48>] (do_raw_spin_lock+0x40/0x140)
[<c0027f68>] (update_mmu_cache+0x208/0x250)
[<c0079db4>] (__do_fault+0x320/0x3ec)
[<c007af7c>] (handle_mm_fault+0x2f0/0x6d8)
[<c0027834>] (do_page_fault+0xdc/0x1cc)
[<c00202d0>] (do_DataAbort+0x34/0x94)
This comes from the fact that when USE_SPLIT_PTLOCKS is not defined,
the only lock protecting the page tables is mm->page_table_lock
which is already locked before update_mmu_cache() is called.
Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 63bfd7384b119409685a17d5c58f0b56e5dc03da upstream.
As pointed out by Linus, commit dab5855 ("perf_counter: Add mmap event hooks to
mprotect()") is fundamentally wrong as mprotect_fixup() can free 'vma' due to
merging. Fix the problem by moving perf_event_mmap() hook to
mprotect_fixup().
Note: there's another successful return path from mprotect_fixup() if old
flags equal to new flags. We don't, however, need to call
perf_event_mmap() there because 'perf' already knows the VMA is
executable.
Reported-by: Dave Jones <davej@redhat.com>
Analyzed-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Reviewed-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 3c6f27bf33052ea6ba9d82369fb460726fb779c0 upstream.
A single uninitialized padding byte is leaked to userspace.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d9bcbf343ec63e1104b5276195888ee06b4d086f upstream.
MMC hosts that poll for card detection by defining the MMC_CAP_NEEDS_POLL
flag have a race on rmmod, where the delayed work is cancelled without
waiting for completed polling. To prevent this a _sync version of the work
cancellation has to be used.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 6c0aca288e726405b01dacb12cac556454d34b2a upstream.
When a single step exception fires, the trap bits, used to
signal hardware breakpoints, are in a random state.
These trap bits might be set if another exception will follow,
like a breakpoint in the next instruction, or a watchpoint in the
previous one. Or there can be any junk there.
So if we handle these trap bits during the single step exception,
we are going to handle an exception twice, or we are going to
handle junk.
Just ignore them in this case.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=21332
Reported-by: Michael Stefaniuc <mstefani@redhat.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
Cc: Alexandre Julliard <julliard@winehq.org>
Cc: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 00fafcda1773245a5292f953321ec3f0668c8c28 upstream.
pm_qos_get_value had min and max reversed, causing all pm_qos
requests to have no effect.
Signed-off-by: Colin Cross <ccross@android.com>
Acked-by: mark <markgross@thegnar.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 04c3496152394d17e3bc2316f9731ee3e8a026bc upstream.
Depending on processor speed, page size, and the amount of memory a
process is allowed to amass, cleanup of a large VM may freeze the system
for many seconds. This can result in a watchdog timeout.
Make sure other tasks receive some service when cleaning up large VMs.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
Cc: Greg Ungerer <gerg@snapgear.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d1d73578e053b981c3611e5a211534290d24a5eb upstream.
According to the comment describing ops_lock in the definition of struct
backlight_device and when comparing with other functions in backlight.c
the mutex must be hold when checking ops to be non-NULL.
Fixes a problem added by c835ee7f4154992e6 ("backlight: Add suspend/resume
support to the backlight core") in Jan 2009.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Richard Purdie <rpurdie@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 69e83dad5207f8f03c9699e57e1febb114383cb8 upstream.
Disable the winch irq early to make sure we don't take an interrupt part
way through the freeing of the handler data, resulting in a crash on
shutdown:
winch_interrupt : read failed, errno = 9
fd 13 is losing SIGWINCH support
------------[ cut here ]------------
WARNING: at lib/list_debug.c:48 list_del+0xc6/0x100()
list_del corruption, next is LIST_POISON1 (00100100)
082578c8: [<081fd77f>] dump_stack+0x22/0x24
082578e0: [<0807a18a>] warn_slowpath_common+0x5a/0x80
08257908: [<0807a23e>] warn_slowpath_fmt+0x2e/0x30
08257920: [<08172196>] list_del+0xc6/0x100
08257940: [<08060244>] free_winch+0x14/0x80
08257958: [<080606fb>] winch_interrupt+0xdb/0xe0
08257978: [<080a65b5>] handle_IRQ_event+0x35/0xe0
08257998: [<080a8717>] handle_edge_irq+0xb7/0x170
082579bc: [<08059bc4>] do_IRQ+0x34/0x50
082579d4: [<08059e1b>] sigio_handler+0x5b/0x80
082579ec: [<0806a374>] sig_handler_common+0x44/0xb0
08257a68: [<0806a538>] sig_handler+0x38/0x50
08257a78: [<0806a77c>] handle_signal+0x5c/0xa0
08257a9c: [<0806be28>] hard_handler+0x18/0x20
08257aac: [<00c14400>] 0xc14400
Signed-off-by: Will Newton <will.newton@gmail.com>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d47844a014fada1a788719f6426bc7044f2a0fd8 upstream.
It seems that using ath9k_hw_stoppcurecv to stop rx dma is not enough.
When it's time to stop DMA, the PCU is still busy, so the rx enable
bit never clears.
Using ath9k_hw_abortpcurecv helps with getting rx stopped much faster,
with this change, I cannot reproduce the rx stop related WARN_ON anymore.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit ba03864872691c0bb580a7fb47388da337ef4aa2 upstream.
The DFS referral parsing code does a memchr() call to find the '\\'
delimiter that separates the hostname in the referral UNC from the
sharename. It then uses that value to set the length of the hostname via
pointer subtraction. Instead of subtracting the start of the hostname
however, it subtracts the start of the UNC, which causes the code to
pass in a hostname length that is 2 bytes too long.
Regression introduced in commit 1a4240f4.
Reported-and-Tested-by: Robbert Kouprie <robbert@exx.nl>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Cc: Wang Lei <wang840925@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a7851ce73b9fdef53f251420e6883cf4f3766534 upstream.
cifs_root_iget allocates full_path through
cifs_build_path_to_root, but fails to kfree it upon
cifs_get_inode_info* failure.
Make all failure exit paths traverse clean up
handling at the end of the function.
Signed-off-by: Oskar Schirmer <oskar@scara.com>
Reviewed-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 1f64d69c7ad2e48e697493e45590679f7a69b7b2 upstream.
Have hugetlb_fault() call unlock_page(page) only if it had previously
called lock_page(page).
Setting CONFIG_DEBUG_VM=y and then running the libhugetlbfs test suite,
resulted in the tripping of VM_BUG_ON(!PageLocked(page)) in
unlock_page() having been called by hugetlb_fault() when page ==
pagecache_page. This patch remedied the problem.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 33dd94ae1ccbfb7bf0fb6c692bc3d1c4269e6177 upstream.
If a user manages to trigger an oops with fs set to KERNEL_DS, fs is not
otherwise reset before do_exit(). do_exit may later (via mm_release in
fork.c) do a put_user to a user-controlled address, potentially allowing
a user to leverage an oops into a controlled write into kernel memory.
This is only triggerable in the presence of another bug, but this
potentially turns a lot of DoS bugs into privilege escalations, so it's
worth fixing. I have proof-of-concept code which uses this bug along
with CVE-2010-3849 to write a zero to an arbitrary kernel address, so
I've tested that this is not theoretical.
A more logical place to put this fix might be when we know an oops has
occurred, before we call do_exit(), but that would involve changing
every architecture, in multiple places.
Let's just stick it in do_exit instead.
[akpm@linux-foundation.org: update code comment]
Signed-off-by: Nelson Elhage <nelhage@ksplice.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 853ff88324a248a9f5da6e110850223db353ec07 upstream.
The AMD Geode CS5536 Companion Device Silicon Revision B1 Specification
Update mentions the follow as issue #36:
"Atomic write transactions to the atomic GPIO High Bank Feature Bit
registers should only affect the bits selected [...]"
"after Suspend, an atomic write transaction [...] will clear all
non-selected bits of the accessed register."
In other words, writing to the high bank for a single GPIO bit will
clear every other GPIO bit (but only sometimes after a suspend).
The workaround described is obvious and simple; do a read-modify-write.
This patch does that, and documents why we're doing it.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a0822c55779d9319939eac69f00bb729ea9d23da upstream.
The attribute cache for a file was not being cleared when a file is opened
with O_TRUNC.
If the filesystem's open operation truncates the file ("atomic_o_trunc"
feature flag is set) then the kernel should invalidate the cached st_mtime
and st_ctime attributes.
Also i_size should be explicitly be set to zero as it is used sometimes
without refreshing the cache.
Signed-off-by: Ken Sumrall <ksumrall@android.com>
Cc: Anfei <anfei.zhou@gmail.com>
Cc: "Anand V. Avati" <avati@gluster.com>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 35bbe587d0959712b69540077c9e0fd27d3e6baf upstream.
The entries for those cards are after the generic entries,
so they don't work, in practice. Moving them to happen before the
generic entres fix the issue.
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 420a0f66378c84b00b0e603e4d38210102dbe367 upstream.
If primary ID (HID) is invalid try locating first valid ID on compatible
ID list before giving up.
This helps, for example, to recognize i8042 AUX port on Sony Vaio VPCZ1
which uses SNYSYN0003 as HID. Without the patch users are forced to
boot with i8042.nopnp to make use of their touchpads.
Tested-by: Jan-Hendrik Zab <jan@jhz.name>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit ed3aada1bf34c5a9e98af167f125f8a740fc726a upstream.
Currently we have:
--w--w--w-. 1 root root 0 2010-11-11 14:56 /sys/kernel/debug/acpi/custom_method
which is just crazy. Change this to --w-------.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit dab5fff14df2cd16eb1ad4c02e83915e1063fece upstream.
We didn't free per_cpu(acfreq_data, cpu)->freq_table
when acpi_freq driver is unloaded.
Resulting in the following messages in /sys/kernel/debug/kmemleak:
unreferenced object 0xf6450e80 (size 64):
comm "modprobe", pid 1066, jiffies 4294677317 (age 19290.453s)
hex dump (first 32 bytes):
00 00 00 00 e8 a2 24 00 01 00 00 00 00 9f 24 00 ......$.......$.
02 00 00 00 00 6a 18 00 03 00 00 00 00 35 0c 00 .....j.......5..
backtrace:
[<c123ba97>] kmemleak_alloc+0x27/0x50
[<c109f96f>] __kmalloc+0xcf/0x110
[<f9da97ee>] acpi_cpufreq_cpu_init+0x1ee/0x4e4 [acpi_cpufreq]
[<c11cd8d2>] cpufreq_add_dev+0x142/0x3a0
[<c11920b7>] sysdev_driver_register+0x97/0x110
[<c11cce56>] cpufreq_register_driver+0x86/0x140
[<f9dad080>] 0xf9dad080
[<c1001130>] do_one_initcall+0x30/0x160
[<c10626e9>] sys_init_module+0x99/0x1e0
[<c1002d97>] sysenter_do_call+0x12/0x26
[<ffffffff>] 0xffffffff
https://bugzilla.kernel.org/show_bug.cgi?id=15807#c21
Tested-by: Toralf Forster <toralf.foerster@gmx.de>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 557d58687dcdee6bc00c1a8f1fd4e0eac8fefce9 upstream.
According to the ACPI spec, some kinds of primary battery can
report percentage battery remaining capacity directly to OS.
In this case, it reports the LastFullChargedCapacity == 100,
BatteryPresentRate = 0xFFFFFFFF, and BatteryRemaingCapacity a
percentage value, which actually means RemainingBatteryPercentage.
Now we found some battery follows this rule even if it's a rechargeable.
https://bugzilla.kernel.org/show_bug.cgi?id=15979
Handle these batteries correctly in ACPI battery driver
so that they won't break userspace.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit b1d248d96c71665c79befb81207f38f894c7c082 upstream.
ACPI table sysfs I/F is broken by commit
78f1699659963fff97975df44db6d5dbe7218e55
Author: Alex Chiang <achiang@hp.com>
Date: Sun Dec 20 12:19:09 2009 -0700
ACPI: processor: call _PDC early
because dynamic SSDT tables may be loaded in _PDC,
before installing the ACPI table handler.
As a result, the sysfs I/F of these dynamic tables are
located at /sys/firmware/acpi/tables instead of
/sys/firmware/acpi/tables/dynamic, which is not true.
Invoke acpi_sysfs_init() before acpi_early_processor_set_pdc(),
so that the table handler is installed before any dynamic tables loaded.
https://bugzilla.kernel.org/show_bug.cgi?id=21142
CC: Dennis Jansen <dennis.jansen@web.de>
CC: Alex Chiang <achiang@hp.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit ab08853fab2093e5c6f5de56827a4c93dce4b055 upstream.
VMWare reports that the e1000 driver has a bug when bringing down the
interface, such that interrupts are not disabled in the hardware but the
driver stops reporting that it consumed the interrupt.
The fix is to set the driver's "down" flag later in the routine,
after all the timers and such have exited, preventing the interrupt
handler from being called and exiting early without handling the
interrupt.
CC: Anupam Chanda <anupamc@vmware.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit abf03184a31a3286fc0ab30f838ddee8ba9f9b7b upstream.
This patch (as1437) fixes a bug in the usb-serial autosuspend
handling. Since the usb-serial core now has autosuspend support, it
must set the .supports_autosuspend member in every serial driver it
registers. Otherwise the usb_autopm_get_interface() call won't work.
This fixes Bugzilla #23012.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Kevin Smith <thirdwiggin@gmail.com>
Reported-and-tested-by: Simon Gerber <gesimu@gmail.com>
Reported-and-tested-by: Matteo Croce <matteo@openwrt.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 6fdbad8021151a9e93af8159a6232c8f26415c09 upstream.
Add the PID for the Vardaan Enterprises VEUSB422R3 USB to RS422/485
converter. It uses the same chip as the FTDI_8U232AM_PID 0x6001.
This should also work with the stable branches for:
2.6.31, 2.6.32, 2.6.33, 2.6.34, 2.6.35, 2.6.36
Signed-off-by: Jacques Viviers <jacques.viviers@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 28942bb6a9dd4e2ed793675e515cfb8297ed355b upstream.
Another variant of the RT Systems programming cable for ham radios.
Signed-off-by: Michael Stuermer <ms@mallorn.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit e24d7ace4e822debcb78386bf279c9aba4d7fbd1 upstream.
They should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Harrison Metzger <harrisonmetz@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d489a4b3926bad571d404ca6508f6744b9602776 upstream.
It should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sam Hocevar <sam@zoy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 48f115470e68d443436b76b22dad63ffbffd6b97 upstream.
They should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit c990600d340641150f7270470a64bd99a5c0b225 upstream.
They should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oliver Bock <bock@tfh-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit e502ac5e1eca99d7dc3f12b2a6780ccbca674858 upstream.
Some of the sysfs files had the incorrect permissions. Some didn't make
sense at all (writable for a file that you could not write to?)
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthieu Castet <castet.matthieu@free.fr>
Cc: Stanislaw Gruszka <stf_xl@wp.pl>
Cc: Damien Bergamini <damien.bergamini@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d9624e75f6ad94d8a0718c1fafa89186d271a78c upstream.
A non-writable sysfs file shouldn't have writable attributes.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kevin Lloyd <klloyd@sierrawireless.com>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a85b4e7f4481c5a1ca89fa63c9c871151965075e upstream.
Tested on MacBookAir3,1. Without this, we get EPROTO errors when
fetching device config descriptors.
Signed-off-by: Brian Tarricone <brian@tarricone.org>
Reported-by: Benoit Gschwind <gschwind@gnu-log.net>
Tested-by: Edgar Hucek <gimli@dark-green.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 02e2c51ba3e80acde600721ea784c3ef84da5ea1 upstream.
This patch (as1435) fixes an obscure and unlikely race in ehci-hcd.
When an async URB is unlinked, the corresponding QH is removed from
the async list. If the QH's endpoint is then disabled while the URB
is being given back, ehci_endpoint_disable() won't find the QH on the
async list, causing it to believe that the QH has been lost. This
will lead to a memory leak at best and quite possibly to an oops.
The solution is to trust usbcore not to lose track of endpoints. If
the QH isn't on the async list then it doesn't need to be taken off
the list, but the driver should still wait for the QH to become IDLE
before disabling it.
In theory this fixes Bugzilla #20182. In fact the race is so rare
that it's not possible to tell whether the bug is still present.
However, adding delays and making other changes to force the race
seems to show that the patch works.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
CC: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 723b991a62d94f74c9f19abd3da6e937288eb969 upstream.
The permissions for the lpm debugfs file is incorrect, this fixes it.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alek Du <alek.du@intel.com>
Cc: Jacob Pan <jacob.jun.pan@intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 251d380034c6c34efe75ffb89d863558ba68ec6a upstream.
BugLink: http://bugs.launchpad.net/bugs/441990
This was tested to successfully enable the hardware.
Signed-off-by: John Tapsell <johnflux@gmail.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 1c0a38038e8fcfaa6b5a81d53a4898f3f939f582 upstream.
platfrom -> platform
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Reviewed-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 886ccd4520064408ce5876cfe00554ce52ecf4a7 upstream.
Structure usbdevfs_connectinfo is copied to userland with padding byted
after "slow" field uninitialized. It leads to leaking of contents of
kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit eca67aaeebd6e5d22b0d991af1dd0424dc703bfb upstream.
Structure iowarrior_info is copied to userland with padding byted
between "serial" and "revision" fields uninitialized. It leads to
leaking of contents of kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Acked-by: Kees Cook <kees.cook@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 5dc92cf1d0b4b0debbd2e333b83f9746c103533d upstream.
Structure sisusb_info is copied to userland with "sisusb_reserved" field
uninitialized. It leads to leaking of contents of kernel stack memory.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 58c0d9d70109bd7e82bdb9517007311a48499960 upstream.
When huawei datacard with PID 0x14AC is insterted into Linux system, the
present kernel will load the "option" driver to all the interfaces. But
actually, some interfaces run as other function and do not need "option"
driver.
In this path, we modify the id_tables, when the PID is 0x14ac ,VID is
0x12d1, Only when the interface's Class is 0xff,Subclass is 0xff, Pro is
0xff, it does need "option" driver.
Signed-off-by: ma rui <m00150988@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 7fea0f714ffb3f303d4b66933af2df2f5584c9bf upstream.
Add the USB IDs for the Milkymist One FTDI-based JTAG/serial adapter
(http://projects.qi-hardware.com/index.php/p/mmone-jtag-serial-cable/)
to the ftdi_sio driver and disable the first serial channel (used as
JTAG from userspace).
Signed-off-by: Sebastien Bourdeauducq <sebastien@milkymist.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit b212091474a5f967979e62c5c24687ee4d0342d9 upstream.
musb driver still may write MUSB_DEVCTL register after clock is disabled
in musb_platform_exit, which may cause the kernel oops[1] when musb_hdrc
module is loaded for the 2nd time.
The patch fixes the kernel oops in this case.
[1] kernel oops when loading musb_hdrc module for the 2nd time
[ 93.380279] musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=5
[ 93.387847] bus: 'platform': add driver musb_hdrc
[ 93.388153] bus: 'platform': driver_probe_device: matched device musb_hdrc with driver musb_hdrc
[ 93.388183] bus: 'platform': really_probe: probing driver musb_hdrc with device musb_hdrc
[ 93.405090] HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0
[ 93.405364] musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
[ 93.405395] musb_hdrc: MHDRC RTL version 1.400
[ 93.405426] musb_hdrc: setup fifo_mode 3
[ 93.405456] musb_hdrc: 7/31 max ep, 3648/16384 memory
[ 93.405487] musb_core_init 1524: musb_hdrc: hw_ep 0shared, max 64
[ 93.405487] musb_core_init 1524: musb_hdrc: hw_ep 1tx, doublebuffer, max 512
[ 93.405517] musb_core_init 1533: musb_hdrc: hw_ep 1rx, doublebuffer, max 512
[ 93.405548] musb_core_init 1524: musb_hdrc: hw_ep 2tx, max 512
[ 93.405578] musb_core_init 1533: musb_hdrc: hw_ep 2rx, max 512
[ 93.405578] musb_core_init 1524: musb_hdrc: hw_ep 3shared, max 256
[ 93.405609] musb_core_init 1524: musb_hdrc: hw_ep 4shared, max 256
[ 93.405853] musb_platform_try_idle 133: b_idle inactive, for idle timer for 7 ms
[ 93.405944] device: 'gadget': device_add
[ 93.406921] PM: Adding info for No Bus:gadget
[ 93.406951] musb_init_controller 2136: OTG mode, status 0, dev80
[ 93.407379] musb_do_idle 51: musb_do_idle: state=1
[ 93.408233] musb_hdrc musb_hdrc: USB OTG mode controller at fa0ab000 using DMA, IRQ 92
[ 93.416656] driver: 'musb_hdrc': driver_bound: bound to device 'musb_hdrc'
[ 93.416687] bus: 'platform': really_probe: bound device musb_hdrc to driver musb_hdrc
[ 124.486938] bus: 'platform': remove driver musb_hdrc
[ 124.490509] twl4030_usb twl4030_usb: twl4030_phy_suspend
[ 124.491424] device: 'gadget': device_unregister
[ 124.491424] PM: Removing info for No Bus:gadget
[ 124.495269] gadget: musb_gadget_release
[ 124.498992] driver: 'musb_hdrc': driver_release
[ 129.569366] musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=5
[ 129.576934] bus: 'platform': add driver musb_hdrc
[ 129.577209] bus: 'platform': driver_probe_device: matched device musb_hdrc with driver musb_hdrc
[ 129.577239] bus: 'platform': really_probe: probing driver musb_hdrc with device musb_hdrc
[ 129.592651] twl4030_usb twl4030_usb: twl4030_phy_resume
[ 129.592681] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab404
[ 129.600830] Internal error: : 1028 [#1]
[ 129.604858] last sysfs file: /sys/devices/platform/i2c_omap.3/i2c-3/i2c-dev/i2c-3/dev
[ 129.613067] Modules linked in: musb_hdrc(+) [last unloaded: musb_hdrc]
[ 129.619964] CPU: 0 Not tainted (2.6.36-next-20101021+ #372)
[ 129.626281] PC is at musb_platform_init+0xb0/0x1c8 [musb_hdrc]
[ 129.632415] LR is at mark_held_locks+0x64/0x94
[ 129.637084] pc : [<bf032198>] lr : [<c00ad7c4>] psr: 20000013
[ 129.637084] sp : c6d5fcb0 ip : c6d5fc38 fp : c6d5fcd4
[ 129.649139] r10: c6e72180 r9 : fa0ab000 r8 : c05612e8
[ 129.654602] r7 : 0000005c r6 : c0559cc8 r5 : c6e72180 r4 : c0561548
[ 129.661468] r3 : 04d60047 r2 : fa0ab000 r1 : c07169d8 r0 : 00000000
[ 129.668304] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 129.675811] Control: 10c5387d Table: 86e4c019 DAC: 00000015
[ 129.681823] Process insmod (pid: 554, stack limit = 0xc6d5e2f0)
[ 129.688049] Stack: (0xc6d5fcb0 to 0xc6d60000)
[ 129.692626] fca0: fa0ab000 c0555c54 c6d5fcd4 c0561548
[ 129.701202] fcc0: 00000003 c05612e0 c6d5fe04 c6d5fcd8 bf03140c bf0320f4 c6d5fd9c c6d5fce8
[ 129.709808] fce0: c015cb94 c041448c c06d9d10 ffffffff c6d5fd14 c6d5fd00 c00adbec c6d5fd40
[ 129.718383] fd00: c015d478 c6d5fdb0 c6d5fd24 c00a9d18 c6d5e000 60000013 bf02a4ac c05612bc
[ 129.726989] fd20: c0414fb4 c00a9cf0 c6d5fd54 c6d5fd38 c015bbdc c0244280 c6e8b7b0 c7929330
[ 129.735565] fd40: c6d5fdb0 c6d5fdb0 c6d5fd7c c6e7227c c015c010 c015bb90 c015c2ac c6d5fdb0
[ 129.744171] fd60: c7929330 c6d5fdb0 c7929330 c6e8b7b0 c6d5fd9c 00000000 c7929330 c6e8b7b0
[ 129.752746] fd80: c6d5fdb0 00000000 00000001 00000000 c6d5fde4 c6d5fda0 c015d478 c015cb74
[ 129.761322] fda0: c056138c 00000000 c6d5fdcc c6d5fdb8 c7929330 00000000 c056138c c05612e8
[ 129.769927] fdc0: 00000000 c05612f0 c0c5d62c c06f6e00 c73217c0 00000000 c6d5fdf4 c05612e8
[ 129.778503] fde0: c05612e8 bf02a2e4 c0c5d62c c06f6e00 c73217c0 00000000 c6d5fe14 c6d5fe08
[ 129.787109] fe00: c029a398 bf0311c8 c6d5fe4c c6d5fe18 c0299120 c029a384 c7919140 22222222
[ 129.795684] fe20: c6d5fe4c c05612e8 c056131c bf02a2e4 c0299278 c06f6e00 c73217c0 00000000
[ 129.804290] fe40: c6d5fe6c c6d5fe50 c0299314 c0299020 00000000 c6d5fe70 bf02a2e4 c0299278
[ 129.812866] fe60: c6d5fe94 c6d5fe70 c02987d4 c0299284 c7825060 c78c6618 00000000 bf02a2e4
[ 129.821441] fe80: c06e4c98 00000000 c6d5fea4 c6d5fe98 c0298ea4 c0298778 c6d5fedc c6d5fea8
[ 129.830047] fea0: c0297f84 c0298e8c bf02716c 000b9008 bf02a2e4 bf02a2d0 000b9008 bf02a2e4
[ 129.838623] fec0: 00000000 c06f6e00 bf031000 00000000 c6d5fefc c6d5fee0 c0299614 c0297ec0
[ 129.847229] fee0: bf02a2d0 000b9008 bf02a388 00000000 c6d5ff0c c6d5ff00 c029a868 c02995a8
[ 129.855804] ff00: c6d5ff24 c6d5ff10 c029a88c c029a818 0010281c 000b9008 c6d5ff34 c6d5ff28
[ 129.864410] ff20: bf03104c c029a878 c6d5ff7c c6d5ff38 c00463dc bf03100c 00000000 00000000
[ 129.872985] ff40: 00000000 0010281c 000b9008 bf02a388 00000000 0010281c 000b9008 bf02a388
[ 129.881591] ff60: 00000000 c00521c8 c6d5e000 00000000 c6d5ffa4 c6d5ff80 c00bb9b8 c00463ac
[ 129.890167] ff80: c00adc88 c00ada68 00097e8e bebbfcf4 0010281c 00000080 00000000 c6d5ffa8
[ 129.898742] ffa0: c0052000 c00bb908 00097e8e bebbfcf4 402c9008 0010281c 000b9008 bebbfe5a
[ 129.907348] ffc0: 00097e8e bebbfcf4 0010281c 00000080 00000014 bebbfcf4 bebbfe06 0000005b
[ 129.915924] ffe0: bebbf9a0 bebbf990 0001a108 40263ec0 60000010 402c9008 011b0000 0000007c
[ 129.924499] Backtrace:
[ 129.927185] [<bf0320e8>] (musb_platform_init+0x0/0x1c8 [musb_hdrc]) from [<bf03140c>] (musb_probe+0x250/0xf2c [musb_hdrc])
[ 129.938781] r6:c05612e0 r5:00000003 r4:c0561548
[ 129.943695] [<bf0311bc>] (musb_probe+0x0/0xf2c [musb_hdrc]) from [<c029a398>] (platform_drv_probe+0x20/0x24)
[ 129.954040] [<c029a378>] (platform_drv_probe+0x0/0x24) from [<c0299120>] (driver_probe_device+0x10c/0x264)
[ 129.964172] [<c0299014>] (driver_probe_device+0x0/0x264) from [<c0299314>] (__driver_attach+0x9c/0xa0)
[ 129.973968] [<c0299278>] (__driver_attach+0x0/0xa0) from [<c02987d4>] (bus_for_each_dev+0x68/0x94)
[ 129.983367] r7:c0299278 r6:bf02a2e4 r5:c6d5fe70 r4:00000000
[ 129.989349] [<c029876c>] (bus_for_each_dev+0x0/0x94) from [<c0298ea4>] (driver_attach+0x24/0x28)
[ 129.998565] r7:00000000 r6:c06e4c98 r5:bf02a2e4 r4:00000000
[ 130.004547] [<c0298e80>] (driver_attach+0x0/0x28) from [<c0297f84>] (bus_add_driver+0xd0/0x274)
[ 130.013671] [<c0297eb4>] (bus_add_driver+0x0/0x274) from [<c0299614>] (driver_register+0x78/0x158)
[ 130.023101] [<c029959c>] (driver_register+0x0/0x158) from [<c029a868>] (platform_driver_register+0x5c/0x60)
[ 130.033325] r7:00000000 r6:bf02a388 r5:000b9008 r4:bf02a2d0
[ 130.039276] [<c029a80c>] (platform_driver_register+0x0/0x60) from [<c029a88c>] (platform_driver_probe+0x20/0xa8)
[ 130.050018] [<c029a86c>] (platform_driver_probe+0x0/0xa8) from [<bf03104c>] (musb_init+0x4c/0x54 [musb_hdrc])
[ 130.060424] r5:000b9008 r4:0010281c
[ 130.064239] [<bf031000>] (musb_init+0x0/0x54 [musb_hdrc]) from [<c00463dc>] (do_one_initcall+0x3c/0x1c0)
[ 130.074218] [<c00463a0>] (do_one_initcall+0x0/0x1c0) from [<c00bb9b8>] (sys_init_module+0xbc/0x1d0)
[ 130.083709] [<c00bb8fc>] (sys_init_module+0x0/0x1d0) from [<c0052000>] (ret_fast_syscall+0x0/0x3c)
[ 130.093109] r7:00000080 r6:0010281c r5:bebbfcf4 r4:00097e8e
[ 130.099090] Code: 0a000046 e3a01001 e12fff33 e59520e4 (e5923404)
[ 130.105621] ---[ end trace 1d0bd69deb79164d ]---
Cc: Ajay Kumar Gupta <ajay.gupta@ti.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit b48809518631880207796b4aab0fc39c2f036754 upstream.
compile fix for bug introduced by 969affff547027)
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 6dd0a3a7e0793dbeae1b951f091025d8cf896cb4 upstream.
Disabling SuperSpeed ports is a Very Bad Thing (TM). It disables
SuperSpeed terminations, which means that devices will never connect at
SuperSpeed on that port. For USB 2.0/1.1 ports, disabling the port meant
that the USB core could always get a connect status change later. That's
not true with USB 3.0 ports.
Do not let the USB core disable SuperSpeed ports. We can't rely on the
device speed in the port status registers, since that isn't valid until
there's a USB device connected to the port. Instead, we use the port
speed array that's created from the Extended Capabilities registers.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit da6699ce4a889c3795624ccdcfe7181cc89f18e8 upstream.
An xHCI host controller contains USB 2.0 and USB 3.0 ports, which can
occur in any order in the PORTSC registers. We cannot read the port speed
bits in the PORTSC registers at init time to determine the port speed,
since those bits are only valid when a USB device is plugged into the
port.
Instead, we read the "Supported Protocol Capability" registers in the xHC
Extended Capabilities space. Those describe the protocol, port offset in
the PORTSC registers, and port count. We use those registers to create
two arrays of pointers to the PORTSC registers, one for USB 3.0 ports, and
another for USB 2.0 ports. A third array keeps track of the port protocol
major revision, and is indexed with the internal xHCI port number.
This commit is a bit big, but it should be queued for stable because the "Don't
let the USB core disable SuperSpeed ports" patch depends on it. There is no
other way to determine which ports are SuperSpeed ports without this patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 7a3783efffc7bc2e702d774e47fad5b8e37e9ad1 upstream.
We have been having problems with the USB-IF Gold Tree tests when plugging
and unplugging devices from the tree. I have seen that the reset-device
and configure-endpoint commands, which are invoked from
xhci_discover_or_reset_device() and xhci_configure_endpoint(), will sometimes
time out.
After much debugging, I determined that the commands themselves do not actually
time out, but rather their completion events do not get delivered to the right
place.
This happens when the command ring has just wrapped around, and it's enqueue
pointer is left pointing to the link TRB. xhci_discover_or_reset_device() and
xhci_configure_endpoint() use the enqueue pointer directly as their command
TRB pointer, without checking whether it's pointing to the link TRB.
When the completion event arrives, if the command TRB is pointing to the link
TRB, the check against the command ring dequeue pointer in
handle_cmd_in_cmd_wait_list() fails, so the completion inside the command does
not get signaled.
The patch below fixes the timeout problem for me.
This should be queued for the 2.6.35 and 2.6.36 stable trees.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit dc07c91b9b4067022210e68d914a6890a4d70622 upstream.
USB2.0 spec 9.6.6 says: For all endpoints, bit 10..0 specify the maximum
packet size(in bytes).
So the wMaxPacketSize mask should be 0x7ff rather than 0x3ff.
This patch should be queued for the stable tree. The bug in
xhci_endpoint_init() was present as far back as 2.6.31, and the bug in
xhci_get_max_esit_payload() was present when the function was introduced
in 2.6.34.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 241b652f1995de138106afd2f2e4eda9f8a3c240 upstream.
If the xHCI host controller shares an interrupt line with another device,
the xHCI driver needs to check if the interrupt was generated by its
hardware. Unfortunately, the user will see a ton of "Spurious interrupt."
lines if the other hardware interrupts often. Lawrence found his dmesg
output cluttered with this output when the xHCI host shared an interrupt
with his i915 hardware.
Remove the warning, as sharing an interrupt is a normal thing.
This should be applied to the 2.6.36 stable tree.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Lawrence Rust <lvr@softsystem.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 8c05cd08a7504b855c265263e84af61aabafa329 upstream.
I just loaded 2.6.37-rc2 on my machines, and I noticed that X no longer starts.
Running an strace of the X server shows that it's doing this:
open("/sys/bus/pci/devices/0000:07:00.0/resource0", O_RDWR) = 10
mmap(NULL, 16777216, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 EINVAL (Invalid argument)
This code seems to be asking for a shared read/write mapping of 16MB worth of
BAR0 starting at file offset 0, and letting the kernel assign a starting
address. Unfortunately, this -EINVAL causes X not to start. Looking into
dmesg, there's a complaint like so:
process "Xorg" tried to map 0x01000000 bytes at page 0x00000000 on 0000:07:00.0 BAR 0 (start 0x 96000000, size 0x 1000000)
...with the following code in pci_mmap_fits:
pci_start = (mmap_api == PCI_MMAP_SYSFS) ?
pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
if (start >= pci_start && start < pci_start + size &&
start + nr <= pci_start + size)
It looks like the logic here is set up such that when the mmap call comes via
sysfs, the check in pci_mmap_fits wants vma->vm_pgoff to be between the
resource's start and end address, and the end of the vma to be no farther than
the end. However, the sysfs PCI resource files always start at offset zero,
which means that this test always fails for programs that mmap the sysfs files.
Given the comment in the original commit
3b519e4ea618b6943a82931630872907f9ac2c2b, I _think_ the old procfs files
require that the file offset be equal to the resource's base address when
mmapping.
I think what we want here is for pci_start to be 0 when mmap_api ==
PCI_MMAP_PROCFS. The following patch makes that change, after which the Matrox
and Mach64 X drivers work again.
Acked-by: Martin Wilck <martin.wilck@ts.fujitsu.com>
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
