| Age | Commit message (Collapse) | Author |
|---|
|
Upstream 252a52aa4fa22a668f019e55b3aac3ff71ec1c29
The PKT_CTRL_CMD_STATUS device ioctl retrieves a pointer to a
pktcdvd_device from the global pkt_devs array. The index into this
array is provided directly by the user and is a signed integer, so the
comparison to ensure that it falls within the bounds of this array will
fail when provided with a negative index.
This can be used to read arbitrary kernel memory or cause a crash due to
an invalid pointer dereference. This can be exploited by users with
permission to open /dev/pktcdvd/control (on many distributions, this is
readable by group "cdrom").
Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
[ Rather than add a cast, just make the function take the right type -Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit d5d3ebe3be5c5123f2d444e186717f45284151e2 upstream.
If r8196 received packets with invalid sctp/igmp(not tcp, udp) checksum, r8196 set skb->ip_summed
wit CHECKSUM_UNNECESSARY. This cause that upper protocol don't check checksum field.
I am not family with r8196 driver. I try to guess the meaning of RxProtoIP and IPFail.
RxProtoIP stands for received IPv4 packet that upper protocol is not tcp and udp.
!(opts1 & IPFail) is true means that driver correctly to check checksum in IPv4 header.
If it's right, I think we should not set ip_summed wit CHECKSUM_UNNECESSARY for my sctp packets
with invalid checksum.
If it's not right, please tell me.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit fccec10b33503a2b1197c8e7a3abd30443bedb08 upstream.
Fix switching device to low-speed mode after resume reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=502974
Reported-and-tested-by: Laurentiu Badea <bugzilla-redhat@wotevah.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit adea1ac7effbddbe60a9de6d63462bfe79289e59 upstream.
While porting GRO to r8169, I found this driver has a bug in its rx
path.
All skbs given to network stack had their ip_summed set to
CHECKSUM_NONE, while hardware said they had correct TCP/UDP checksums.
The reason is driver sets skb->ip_summed on the original skb before the
copy eventually done by copybreak. The fresh skb gets the ip_summed =
CHECKSUM_NONE value, forcing network stack to recompute checksum, and
preventing my GRO patch to work.
Fix is to make the ip_summed setting after skb copy.
Note : rx_copybreak current value is 16383, so all frames are copied...
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit c054a076a1bd4731820a9c4d638b13d5c9bf5935 upstream.
On certain VIA chipsets AES-CBC requires the input/output to be
a multiple of 64 bytes. We had a workaround for this but it was
buggy as it sent the whole input for processing when it is meant
to only send the initial number of blocks which makes the rest
a multiple of 64 bytes.
As expected this causes memory corruption whenever the workaround
kicks in.
Reported-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
[Note that the mainline will not have this particular fix but rather
will blacklist entire VAIO line based off DMI board name. For stable
I am being a bit more cautious and blacklist one particular product.]
Trying to query/activate active multiplexing mode on this VAIO makes
both keyboard and touchpad inoperable. Futher kernels will blacklist
entire VAIO line, however here we blacklist just one particular model.
Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit 8b14d7b22c61f17ccb869e0047d9df6dd9f50a9f upstream.
While looking for the duplicates in /sys/class/wmi/, I couldn't find
them. The code that looks for duplicates uses strncmp in a binary GUID,
which may contain zero bytes. The right function is memcmp, which is
also used in another section of wmi code.
It was finding 49142400-C6A3-40FA-BADB-8A2652834100 as a duplicate of
39142400-C6A3-40FA-BADB-8A2652834100. Since the first byte is the fourth
printed, they were found as equal by strncmp.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit b9f515e3e3861abbaa093359f7c6f31283695228 upstream.
This patch fixes a compilation issue when compiling PCMCIA SA1100
support as a module with PCMCIA_DEBUG enabled. The symbol
soc_pcmcia_debug was not beeing exported.
ARM: pcmcia: Fix for building DEBUG with sa11xx_base.c as a module.
This patch fixes a compilation issue when compiling PCMCIA SA1100
support as a module with PCMCIA_DEBUG enabled. The symbol
soc_pcmcia_debug was not beeing exported.
Signed-off-by: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit b6faaae1a15a352d68b3e3cd8b840e56709820bf upstream.
eth_type_trans tries to pull data with the length of the ethernet header
from the skb. We only ensured that enough data for the first ethernet
header and the batman header is available in non-paged memory of the skb
and not for the ethernet after the batman header.
eth_type_trans would fail sometimes with drivers which don't ensure that
all there data is perfectly linearised.
The failure was noticed through a kernel bug Oops generated by the
skb_pull inside eth_type_trans.
Reported-by: Rafal Lesniak <lesniak@eresi-project.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit f36d83a8cb7224f45fdfa1129a616dff56479a09 upstream.
This driver issues a kernel panic over conditions that do not
justify such drastic action. Change these to log entries with
a stack dump.
This patch fixes the system crash reported in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674285.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Reported-and-Tested-by: Robie Basik <rb-oss-3@justgohome.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 3bad28ec006ad6ab2bca4e5103860b75391e3c9d and
2a767fda5d0d8dcff465724dfad6ee131489b3f2 upstream merged together.
They should not be writable by any user
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Taht <d@teklibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit 4d7bc388b44e42a1feafa35e50eef4f24d6ca59d upstream.
They should be writable by root, not readable.
Doh, stupid me with the wrong flags.
Reported-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit 90c05b97fdec8d2196e420d98f774bab731af7aa 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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit c9e51d9e4bee3da47623622884f4828e079a0581 upstream.
They should be writable by root, not readable.
Doh, stupid me with the wrong flags.
Reported-by: Jonathan Cameron <jic23@cam.ac.uk>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Cc: Barry Song <Barry.Song@analog.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit 1d904e8950c86e670ace237eaea1d48cd81e94df upstream.
They should not be writable by any user
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Cc: Barry Song <Barry.Song@analog.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit cc9ca9dfddda46b1802d325891a69d7efdbe1f1e and
cc9ca9dfddda46b1802d325891a69d7efdbe1f1e upstream merged together.
They should not be writable by any user
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit 50d431e8a15701b599c98afe2b464eb33c952477 upstream.
While running randconfg with ktest.pl I stumbled upon this bug:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
IP: [<ffffffff815fe44f>] strstr+0x39/0x86
PGD 0
Oops: 0000 [#1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.37-rc1-test+ #6 DG965MQ/
RIP: 0010:[<ffffffff815fe44f>] [<ffffffff815fe44f>] strstr+0x39/0x86
RSP: 0018:ffff8800797cbd80 EFLAGS: 00010213
RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffffffffffff
RDX: 0000000000000000 RSI: ffffffff82eb7ac9 RDI: 0000000000000003
RBP: ffff8800797cbda0 R08: ffff880000000003 R09: 0000000000030725
R10: ffff88007d294c00 R11: 0000000000014c00 R12: 0000000000000020
R13: ffffffff82eb7ac9 R14: ffffffffffffffff R15: ffffffff82eb7b08
FS: 0000000000000000(0000) GS:ffff88007d200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000003 CR3: 0000000002a1d000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff8800797ca000, task ffff8800797d0000)
Stack:
00000000000000ba ffffffff82eb7ac9 ffffffff82eb7ab8 00000000000000ba
ffff8800797cbdf0 ffffffff81e2050f ffff8800797cbdc0 00000000815f913b
ffff8800797cbe00 ffffffff82eb7ab8 0000000000000000 0000000000000000
Call Trace:
[<ffffffff81e2050f>] dmi_matches+0x117/0x154
[<ffffffff81e205d7>] dmi_check_system+0x3d/0x8d
[<ffffffff82e1ad25>] ? nas_gpio_init+0x0/0x2c8
[<ffffffff82e1ad49>] nas_gpio_init+0x24/0x2c8
[<ffffffff820d750d>] ? wm8350_led_init+0x0/0x20
[<ffffffff82e1ad25>] ? nas_gpio_init+0x0/0x2c8
[<ffffffff810022f7>] do_one_initcall+0xab/0x1b2
[<ffffffff82da749c>] kernel_init+0x248/0x331
[<ffffffff8100e624>] kernel_thread_helper+0x4/0x10
[<ffffffff82da7254>] ? kernel_init+0x0/0x331
Found that the nas_led_whitelist dmi_system_id structure array had no
NULL end delimiter, causing the dmi_check_system() loop to read an
undefined entry.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Dave Hansen <dave@sr71.net>
Acked-by: Richard Purdie <rpurdie@linux.intel.com>
Acked-by: Arjan van de Ven <arjan@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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
CC: David Brownell <david-b@pacbell.net>
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit 3b519e4ea618b6943a82931630872907f9ac2c2b upstream.
The checks for valid mmaps of PCI resources made through /proc/bus/pci files
that were introduced in 9eff02e2042f96fb2aedd02e032eca1c5333d767 have several
problems:
1. mmap() calls on /proc/bus/pci files are made with real file offsets > 0,
whereas under /sys/bus/pci/devices, the start of the resource corresponds
to offset 0. This may lead to false negatives in pci_mmap_fits(), which
implicitly assumes the /sys/bus/pci/devices layout.
2. The loop in proc_bus_pci_mmap doesn't skip empty resouces. This leads
to false positives, because pci_mmap_fits() doesn't treat empty resources
correctly (the calculated size is 1 << (8*sizeof(resource_size_t)-PAGE_SHIFT)
in this case!).
3. If a user maps resources with BAR > 0, pci_mmap_fits will emit bogus
WARNINGS for the first resources that don't fit until the correct one is found.
On many controllers the first 2-4 BARs are used, and the others are empty.
In this case, an mmap attempt will first fail on the non-empty BARs
(including the "right" BAR because of 1.) and emit bogus WARNINGS because
of 3., and finally succeed on the first empty BAR because of 2.
This is certainly not the intended behaviour.
This patch addresses all 3 issues.
Updated with an enum type for the additional parameter for pci_mmap_fits().
Signed-off-by: Martin Wilck <martin.wilck@ts.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
|
commit 2a5f07b5ec098edc69e05fdd2f35d3fbb1235723 upstream.
SCSI commands may be issued between __scsi_add_device() and dev->sdev
assignment, so it's unsafe for ata_qc_complete() to dereference
dev->sdev->locked without checking whether it's NULL or not. Fix it.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
