OSDN Git Service
Sarah Sharp [Thu, 16 Jun 2011 02:57:46 +0000 (19:57 -0700)]
xhci: Always set urb->status to zero for isoc endpoints.
commit
b3df3f9c7df9a8d85e03e158d35487618a160901 upstream.
When the xHCI driver encounters a Missed Service Interval event for an
isochronous endpoint ring, it means the host controller skipped over
one or more isochronous TDs. For TD that is skipped, skip_isoc_td() is
called. This sets the frame descriptor status to -EXDEV, and also sets
the value stored in the int pointed to by status to -EXDEV.
If the isochronous TD happens to be the last TD in an URB,
handle_tx_event() will use the status variable to give back the URB to
the USB core. That means drivers will see urb->status as -EXDEV.
It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for
an isochronous urb, regardless of what the frame status is. See
itd_complete() in ehci-sched.c:
} else {
/* URB was too late */
desc->status = -EXDEV;
}
}
/* handle completion now? */
if (likely ((urb_index + 1) != urb->number_of_packets))
goto done;
/* ASSERT: it's really the last itd for this urb
list_for_each_entry (itd, &stream->td_list, itd_list)
BUG_ON (itd->urb == urb);
*/
/* give urb back to the driver; completion often (re)submits */
dev = urb->dev;
ehci_urb_done(ehci, urb, 0);
ehci_urb_done() completes the URB with the status of the third argument, which
is always zero in this case.
It turns out that many USB webcam drivers, such as uvcvideo, cannot
handle urb->status set to a non-zero value. They will not resubmit
their isochronous URBs in that case, and userspace will see a frozen
video.
Change the xHCI driver to be consistent with the EHCI and UHCI driver,
and always set urb->status to 0 for isochronous URBs.
This patch should be backported to kernels as old as 2.6.36
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <Andiry.Xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Maarten Lankhorst [Wed, 15 Jun 2011 21:47:21 +0000 (23:47 +0200)]
xhci: Add reset on resume quirk for asrock p67 host
commit
c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 upstream.
The asrock p67 xhci controller completely dies on resume, add a
quirk for this, to bring the host back online after a suspend.
This should be backported to stable kernels as old as 2.6.37.
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>
Sarah Sharp [Mon, 6 Jun 2011 06:10:04 +0000 (23:10 -0700)]
xhci: Reject double add of active endpoints.
commit
fa75ac379e63c2864e9049b5e8615e40f65c1e70 upstream.
While trying to switch a UAS device from the BOT configuration to the UAS
configuration via the bConfigurationValue file, Tanya ran into an issue in
the USB core. usb_disable_device() sets entries in udev->ep_out and
udev->ep_out to NULL, but doesn't call into the xHCI bandwidth management
functions to remove the BOT configuration endpoints from the xHCI host's
internal structures.
The USB core would then attempt to add endpoints for the UAS
configuration, and some of the endpoints had the same address as endpoints
in the BOT configuration. The xHCI driver blindly added the endpoints
again, but the xHCI host controller rejected the Configure Endpoint
command because active endpoints were added without being dropped.
Make the xHCI driver reject calls to xhci_add_endpoint() that attempt to
add active endpoints without first calling xhci_drop_endpoint().
This should be backported to kernels as old as 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Tanya Brokhman <tlinder@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
K. Y. Srinivasan [Tue, 17 May 2011 22:25:38 +0000 (15:25 -0700)]
Connector: Correctly set the error code in case of success when dispatching receive callbacks
commit
663dd6dcaf7e95526e469e91f41972a9c0cca30c upstream.
The recent changes to the connector code introduced this bug where even
when a callback was invoked, we would return an error resulting in
double freeing of the skb. This patch fixes this bug.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
K. Y. Srinivasan [Tue, 17 May 2011 22:25:37 +0000 (15:25 -0700)]
Connector: Set the CN_NETLINK_USERS correctly
commit
ea2c00095c022846dd8dfd211de05154d3e4e1b8 upstream.
The CN_NETLINK_USERS must be set to the highest valid index +1.
Thanks to Evgeniy for pointing this out.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jiri Slaby [Sun, 5 Jun 2011 12:16:16 +0000 (14:16 +0200)]
TTY: ldisc, do not close until there are readers
commit
92f6fa09bd453ffe3351fa1f1377a1b7cfa911e6 upstream.
We restored tty_ldisc_wait_idle in
100eeae2c5c (TTY: restore
tty_ldisc_wait_idle). We used it in the ldisc changing path to fix the
case where there are tasks in n_tty_read waiting for data and somebody
tries to change ldisc.
Similar to the case above, there may be also tasks waiting in
n_tty_read while hangup is performed. As
65b770468e98 (tty-ldisc: turn
ldisc user count into a proper refcount) removed the wait-until-idle
from all paths, hangup path won't wait for them to disappear either
now. So add it back even to the hangup path.
There is a difference, we need uninterruptible sleep as there is
obviously HUP signal pending. So tty_ldisc_wait_idle now sleeps
without possibility to be interrupted. This is what original
tty_ldisc_wait_idle did. After the wait idle reintroduction
(
100eeae2c5c), we have had interruptible sleeps for the ldisc changing
path. But as there is a 5s timeout anyway, we don't allow it to be
interrupted from now on. It's not worth the added complexity of
deciding what kind of sleep we want.
Before
65b770468e98 tty_ldisc_release was called also from
tty_ldisc_release. It is called from tty_release, so I don't think we
need to restore that one.
This is nicely reproducible after constifying the timing when
drivers/tty/n_tty.c is patched as follows ("TTY: ntty, add one more
sanity check" patch is needed to actually see it explode):
%% -1548,6 +1549,7 @@ static int n_tty_open(struct tty_struct *tty)
/* These are ugly. Currently a malloc failure here can panic */
if (!tty->read_buf) {
+ msleep(100);
tty->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL);
if (!tty->read_buf)
return -ENOMEM;
%% -1785,6 +1788,7 @@ do_it_again:
break;
}
timeout = schedule_timeout(timeout);
+ msleep(20);
continue;
}
__set_current_state(TASK_RUNNING);
===== With a process: =====
while (1) {
int fd = open(argv[1], O_RDWR);
read(fd, buf, sizeof(buf));
close(fd);
}
===== and its child: =====
setsid();
while (1) {
int fd = open(tty, O_RDWR|O_NOCTTY);
ioctl(fd, TIOCSCTTY, 1);
vhangup();
close(fd);
usleep(100 * (10 + random() % 1000));
}
===== EOF =====
References: https://bugzilla.novell.com/show_bug.cgi?id=693374
References: https://bugzilla.novell.com/show_bug.cgi?id=694509
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Boojin Kim [Sat, 28 May 2011 02:04:03 +0000 (19:04 -0700)]
ARM: SAMSUNG: serial: Fix on handling of one clock source for UART
commit
470f22975448a65a1084a6f0721fa5df15323f02 upstream.
This patch fixes the way of comparison for handling of two or more
clock sources for UART.
For example, if just only one clock source is defined even though
there are two clock sources for UART, the serial driver does not
set proper clock up. Of course, it is problem.
So this patch changes the condition of comparison to avoid useless
setup clock and adds a flag 'NO_NEED_CHECK_CLKSRC' which means
selection of source clock is not required.
In addition, since the Exynos4210 has only one clock source for UART
this patch adds the flag into its common_init_uarts().
Signed-off-by: Boojin Kim <boojin.kim@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Thu, 16 Jun 2011 14:22:08 +0000 (16:22 +0200)]
clocksource: Make watchdog robust vs. interruption
commit
b5199515c25cca622495eb9c6a8a1d275e775088 upstream.
The clocksource watchdog code is interruptible and it has been
observed that this can trigger false positives which disable the TSC.
The reason is that an interrupt storm or a long running interrupt
handler between the read of the watchdog source and the read of the
TSC brings the two far enough apart that the delta is larger than the
unstable treshold. Move both reads into a short interrupt disabled
region to avoid that.
Reported-and-tested-by: Vernon Mauery <vernux@us.ibm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Konrad Rzeszutek Wilk [Wed, 6 Jul 2011 13:43:16 +0000 (09:43 -0400)]
xen/pci: Move check for acpi_sci_override_gsi to xen_setup_acpi_sci.
commit
ee339fe63ac408e4604c1c88b1f9a428f2511b70 upstream.
Previously we would check for acpi_sci_override_gsi == gsi every time
a PCI device was enabled. That works during early bootup, but later
on it could lead to triggering unnecessarily the acpi_gsi_to_irq(..) lookup.
The reason is that acpi_sci_override_gsi was declared in __initdata and
after early bootup could contain bogus values.
This patch moves the check for acpi_sci_override_gsi to the
site where the ACPI SCI is preset.
Reported-by: Raghavendra D Prabhu <rprabhu@wnohang.net>
Tested-by: Raghavendra D Prabhu <rprabhu@wnohang.net>
[http://lists.xensource.com/archives/html/xen-devel/2011-07/msg00154.html]
Suggested-by: Ian Campbell <ijc@hellion.org.uk>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Konrad Rzeszutek Wilk [Thu, 30 Jun 2011 13:12:40 +0000 (09:12 -0400)]
xen/mmu: Fix for linker errors when CONFIG_SMP is not defined.
commit
32dd11942aeb47f91209a446d6b10063c5b69389 upstream.
Simple enough - we use an extern defined symbol which is not
defined when CONFIG_SMP is not defined. This fixes the linker
dying.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Konrad Rzeszutek Wilk [Thu, 30 Jun 2011 13:18:27 +0000 (09:18 -0400)]
xen/pci: Use the INT_SRC_OVR IRQ (instead of GSI) to preset the ACPI SCI IRQ.
commit
155a16f21923bc2f04161ac92acca986371ef27b upstream.
In the past we would use the GSI value to preset the ACPI SCI
IRQ which worked great as GSI == IRQ:
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
While that is most often seen, there are some oddities:
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
which means that GSI 20 (or pin 20) is to be overriden for IRQ 9.
Our code that presets the interrupt for ACPI SCI however would
use the GSI 20 instead of IRQ 9 ending up with:
xen: sci override: global_irq=20 trigger=0 polarity=1
xen: registering gsi 20 triggering 0 polarity 1
xen: --> pirq=20 -> irq=20
xen: acpi sci 20
.. snip..
calling acpi_init+0x0/0xbc @ 1
ACPI: SCI (IRQ9) allocation failed
ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (
20110413/evevent-119)
ACPI: Unable to start the ACPI Interpreter
as the ACPI interpreter made a call to 'acpi_gsi_to_irq' which got nine.
It used that value to request an IRQ (request_irq) and since that was not
present it failed.
The fix is to recognize that for interrupts that are overriden (in our
case we only care about the ACPI SCI) we should use the IRQ number
to present the IRQ instead of the using GSI. End result is that we get:
xen: sci override: global_irq=20 trigger=0 polarity=1
xen: registering gsi 20 triggering 0 polarity 1
xen: --> pirq=20 -> irq=9 (gsi=9)
xen: acpi sci 9
which fixes the ACPI interpreter failing on startup.
Reported-by: Liwei <xieliwei@gmail.com>
Tested-by: Liwei <xieliwei@gmail.com>
[http://lists.xensource.com/archives/html/xen-devel/2011-06/msg01727.html]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stefano Stabellini [Fri, 3 Jun 2011 09:51:34 +0000 (09:51 +0000)]
xen: partially revert "xen: set max_pfn_mapped to the last pfn mapped"
commit
a91d92875ee94e4703fd017ccaadb48cfb344994 upstream.
We only need to set max_pfn_mapped to the last pfn mapped on x86_64 to
make sure that cleanup_highmap doesn't remove important mappings at
_end.
We don't need to do this on x86_32 because cleanup_highmap is not called
on x86_32. Besides lowering max_pfn_mapped on x86_32 has the unwanted
side effect of limiting the amount of memory available for the 1:1
kernel pagetable allocation.
This patch reverts the x86_32 part of the original patch.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrew Jones [Fri, 18 Dec 2009 09:31:31 +0000 (10:31 +0100)]
xen: support CONFIG_MAXSMP
commit
900cba8881b39dfbc7c8062098504ab93f5387a8 upstream.
The MAXSMP config option requires CPUMASK_OFFSTACK, which in turn
requires we init the memory for the maps while we bring up the cpus.
MAXSMP also increases NR_CPUS to 4096. This increase in size exposed an
issue in the argument construction for multicalls from
xen_flush_tlb_others. The args should only need space for the actual
number of cpus.
Also in 2.6.39 it exposes a bootup problem.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<
ffffffff8157a1d3>] set_cpu_sibling_map+0x123/0x30d
...
Call Trace:
[<
ffffffff81039a3f>] ? xen_restore_fl_direct_reloc+0x4/0x4
[<
ffffffff819dc4db>] xen_smp_prepare_cpus+0x36/0x135
..
Signed-off-by: Andrew Jones <drjones@redhat.com>
[v2: Updated to compile on 3.0]
[v3: Updated to compile when CONFIG_SMP is not defined]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wolfram Sang [Wed, 15 Jun 2011 09:26:47 +0000 (11:26 +0200)]
drm: populate irq_by_busid-member for pci
commit
45e97ab65026a3391cb2c938f834ca5db4d2e5b3 upstream.
Commit 8410ea (drm: rework PCI/platform driver interface) implemented
drm_pci_irq_by_busid() but forgot to make it available in the
drm_pci_bus-struct.
This caused a freeze on my Radeon9600-equipped laptop when executing glxgears.
Thanks to Michel for noticing the flaw.
[airlied: made function static also]
Reported-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel J Blueman [Fri, 17 Jun 2011 18:32:19 +0000 (11:32 -0700)]
drm/i915: Fix gen6 (SNB) missed BLT ring interrupts.
commit
498e720b96379d8ee9c294950a01534a73defcf3 upstream.
The failure appeared in dmesg as:
[drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt
ring idle [waiting on
35064155, at
35064155], missed IRQ?
This works around that problem on by making the blitter command
streamer write interrupt state to the Hardware Status Page when a
MI_USER_INTERRUPT command is decoded, which appears to force the seqno
out to memory before the interrupt happens.
v1->v2: Moved to prior interrupt handler installation and RMW flags as
per feedback.
v2->v3: Removed RMW of flags (by anholt)
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> [v1]
Tested-by: Eric Anholt <eric@anholt.net> [v1,v3]
(incidence of the bug with a testcase went from avg 2/1000 to
0/12651 in the latest test run (plus more for v1))
Tested-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
Tested-by: Robert Hooker <robert.hooker@canonical.com> [v1]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33394
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Deucher [Thu, 30 Jun 2011 12:59:55 +0000 (08:59 -0400)]
drm/radeon/kms: Fix chremap setup on RV770 CE
commit
daf54f1f363a61c618662ef66d4bf09d2b090941 upstream.
CE variant requires a different chremap setup.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=35472
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>
Alex Deucher [Fri, 17 Jun 2011 17:13:52 +0000 (13:13 -0400)]
drm/radeon/kms/atom: fix duallink on some early DCE3.2 cards
commit
8323fa6ba313ae2664420ec34d56a7fb0bbbe525 upstream.
Certain revisions of the vbios on DCE3.2 cards have a bug
in the transmitter control table which prevents duallink from
being enabled properly on some cards. The action switch statement
jumps to the wrong offset for the OUTPUT_ENABLE action. The fix
is to use the ENABLE action rather than the OUTPUT_ENABLE action
on the affected cards. In fixed version of the vbios, both
actions jump to the same offset, so the change should be safe.
Reported-and-tested-by: Dave Airlie <airlied@redhat.com>
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>
Jean Delvare [Sat, 4 Jun 2011 19:34:56 +0000 (19:34 +0000)]
Revert "drm/i915: Enable GMBUS for post-gen2 chipsets"
commit
826c7e4147f902737b281e8a5a7d7aa33fd63316 upstream.
Revert commit
8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f. This fixes a
hang when loading the eeprom driver (see bug #35572.) GMBUS will be
re-enabled later, differently.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Reported-by: Marek Otahal <markotahal@gmail.com>
Tested-by: Yermandu Patapitafious <yermandu.dev@gmail.com>
Tested-by: Andrew Lutomirski <luto@mit.edu>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Guenter Roeck [Tue, 24 May 2011 19:34:12 +0000 (12:34 -0700)]
hwmon: (ibmpex) Initialize sysfs attributes
commit
fb794e0f7153918c33f2300986d995524ab711cf upstream.
Initialize dynamically allocated sysfs attributes before device_create_file()
call to suppress lockdep_init_map() warning if lockdep debugging is enabled.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Guenter Roeck [Tue, 24 May 2011 19:34:55 +0000 (12:34 -0700)]
hwmon: (s3c) Initialize sysfs attributes
commit
b1e698db0939b04602ded2a2196ff69c92b49378 upstream.
Initialize dynamically allocated sysfs attributes before device_create_file()
call to suppress lockdep_init_map() warning if lockdep debugging is enabled.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Guenter Roeck [Tue, 24 May 2011 19:33:26 +0000 (12:33 -0700)]
hwmon: (ibmaem) Initialize sysfs attributes
commit
3cdb2052a6e365ad56202874e6a8a05a2bb336fc upstream.
Initialize dynamically allocated sysfs attributes before device_create_file()
call to suppress lockdep_init_map() warning if lockdep debugging is enabled.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrea Arcangeli [Thu, 16 Jun 2011 19:56:19 +0000 (12:56 -0700)]
migrate: don't account swapcache as shmem
commit
99a15e21d96f6857dafab1e5167e5e8183215c9c upstream.
swapcache will reach the below code path in migrate_page_move_mapping,
and swapcache is accounted as NR_FILE_PAGES but it's not accounted as
NR_SHMEM.
Hugh pointed out we must use PageSwapCache instead of comparing
mapping to &swapper_space, to avoid build failure with CONFIG_SWAP=n.
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alexander Stein [Wed, 15 Jun 2011 22:08:55 +0000 (15:08 -0700)]
drivers/tty/serial/pch_uart.c: don't oops if dmi_get_system_info returns NULL
commit
fb139dfeef9558a12ffdbf9e26951fd1a9304f3b upstream.
If dmi_get_system_info() returns NULL, pch_uart_init_port() will
dereferencea a zero pointer.
This oops was observed on an Atom based board which has no BIOS, but
a bootloder which doesn't provide DMI data.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.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>
Hugh Dickins [Wed, 15 Jun 2011 22:08:58 +0000 (15:08 -0700)]
ksm: fix NULL pointer dereference in scan_get_next_rmap_item()
commit
2b472611a32a72f4a118c069c2d62a1a3f087afd upstream.
Andrea Righi reported a case where an exiting task can race against
ksmd::scan_get_next_rmap_item (http://lkml.org/lkml/2011/6/1/742) easily
triggering a NULL pointer dereference in ksmd.
ksm_scan.mm_slot == &ksm_mm_head with only one registered mm
CPU 1 (__ksm_exit) CPU 2 (scan_get_next_rmap_item)
list_empty() is false
lock slot == &ksm_mm_head
list_del(slot->mm_list)
(list now empty)
unlock
lock
slot = list_entry(slot->mm_list.next)
(list is empty, so slot is still ksm_mm_head)
unlock
slot->mm == NULL ... Oops
Close this race by revalidating that the new slot is not simply the list
head again.
Andrea's test case:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#define BUFSIZE getpagesize()
int main(int argc, char **argv)
{
void *ptr;
if (posix_memalign(&ptr, getpagesize(), BUFSIZE) < 0) {
perror("posix_memalign");
exit(1);
}
if (madvise(ptr, BUFSIZE, MADV_MERGEABLE) < 0) {
perror("madvise");
exit(1);
}
*(char *)NULL = 0;
return 0;
}
Reported-by: Andrea Righi <andrea@betterlinux.com>
Tested-by: Andrea Righi <andrea@betterlinux.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
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>
Xufeng Zhang [Tue, 21 Jun 2011 10:43:40 +0000 (10:43 +0000)]
udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet
[ Upstream commit
9cfaa8def1c795a512bc04f2aec333b03724ca2e ]
Consider this scenario: When the size of the first received udp packet
is bigger than the receive buffer, MSG_TRUNC bit is set in msg->msg_flags.
However, if checksum error happens and this is a blocking socket, it will
goto try_again loop to receive the next packet. But if the size of the
next udp packet is smaller than receive buffer, MSG_TRUNC flag should not
be set, but because MSG_TRUNC bit is not cleared in msg->msg_flags before
receive the next packet, MSG_TRUNC is still set, which is wrong.
Fix this problem by clearing MSG_TRUNC flag when starting over for a
new packet.
Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Xufeng Zhang [Tue, 21 Jun 2011 10:43:39 +0000 (10:43 +0000)]
ipv6/udp: Use the correct variable to determine non-blocking condition
[ Upstream commit
32c90254ed4a0c698caa0794ebb4de63fcc69631 ]
udpv6_recvmsg() function is not using the correct variable to determine
whether or not the socket is in non-blocking operation, this will lead
to unexpected behavior when a UDP checksum error occurs.
Consider a non-blocking udp receive scenario: when udpv6_recvmsg() is
called by sock_common_recvmsg(), MSG_DONTWAIT bit of flags variable in
udpv6_recvmsg() is cleared by "flags & ~MSG_DONTWAIT" in this call:
err = sk->sk_prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT,
flags & ~MSG_DONTWAIT, &addr_len);
i.e. with udpv6_recvmsg() getting these values:
int noblock = flags & MSG_DONTWAIT
int flags = flags & ~MSG_DONTWAIT
So, when udp checksum error occurs, the execution will go to
csum_copy_err, and then the problem happens:
csum_copy_err:
...............
if (flags & MSG_DONTWAIT)
return -EAGAIN;
goto try_again;
...............
But it will always go to try_again as MSG_DONTWAIT has been cleared
from flags at call time -- only noblock contains the original value
of MSG_DONTWAIT, so the test should be:
if (noblock)
return -EAGAIN;
This is also consistent with what the ipv4/udp code does.
Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marcus Meissner [Thu, 2 Jun 2011 04:05:22 +0000 (21:05 -0700)]
net/ipv4: Check for mistakenly passed in non-IPv4 address
[ Upstream commit
d0733d2e29b652b2e7b1438ececa732e4eed98eb ]
Check against mistakenly passing in IPv6 addresses (which would result
in an INADDR_ANY bind) or similar incompatible sockaddrs.
Signed-off-by: Marcus Meissner <meissner@suse.de>
Cc: Reinhard Max <max@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Fri, 17 Jun 2011 20:25:39 +0000 (16:25 -0400)]
inet_diag: fix inet_diag_bc_audit()
[ Upstream commit
eeb1497277d6b1a0a34ed36b97e18f2bd7d6de0d ]
A malicious user or buggy application can inject code and trigger an
infinite loop in inet_diag_bc_audit()
Also make sure each instruction is aligned on 4 bytes boundary, to avoid
unaligned accesses.
Reported-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Tue, 7 Jun 2011 05:42:06 +0000 (22:42 -0700)]
af_packet: prevent information leak
[ Upstream commit
13fcb7bd322164c67926ffe272846d4860196dc6 ]
In 2.6.27, commit
393e52e33c6c2 (packet: deliver VLAN TCI to userspace)
added a small information leak.
Add padding field and make sure its zeroed before copy to user.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alexander Holler [Tue, 7 Jun 2011 07:51:35 +0000 (00:51 -0700)]
bridge: provide a cow_metrics method for fake_ops
[ Upstream commit
6407d74c5106bb362b4087693688afd34942b094 ]
Like in commit
0972ddb237 (provide cow_metrics() methods to blackhole
dst_ops), we must provide a cow_metrics for bridges fake_dst_ops as
well.
This fixes a regression coming from commits
62fa8a846d7d (net: Implement
read-only protection and COW'ing of metrics.) and
33eb9873a28 (bridge:
initialize fake_rtable metrics)
ip link set mybridge mtu 1234
-->
[ 136.546243] Pid: 8415, comm: ip Tainted: P
2.6.39.1-00006-g40545b7 #103 ASUSTeK Computer Inc. V1Sn
/V1Sn
[ 136.546256] EIP: 0060:[<
00000000>] EFLAGS:
00010202 CPU: 0
[ 136.546268] EIP is at 0x0
[ 136.546273] EAX:
f14a389c EBX:
000005d4 ECX:
f80d32c0 EDX:
f80d1da1
[ 136.546279] ESI:
f14a3000 EDI:
f255bf10 EBP:
f15c3b54 ESP:
f15c3b48
[ 136.546285] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 136.546293] Process ip (pid: 8415, ti=
f15c2000 task=
f4741f80
task.ti=
f15c2000)
[ 136.546297] Stack:
[ 136.546301]
f80c658f f14a3000 ffffffed f15c3b64 c12cb9c8 f80d1b80
ffffffa1 f15c3bbc
[ 136.546315]
c12da347 c12d9c7d 00000000 f7670b00 00000000 f80d1b80
ffffffa6 f15c3be4
[ 136.546329]
00000004 f14a3000 f255bf20 00000008 f15c3bbc c11d6cae
00000000 00000000
[ 136.546343] Call Trace:
[ 136.546359] [<
f80c658f>] ? br_change_mtu+0x5f/0x80 [bridge]
[ 136.546372] [<
c12cb9c8>] dev_set_mtu+0x38/0x80
[ 136.546381] [<
c12da347>] do_setlink+0x1a7/0x860
[ 136.546390] [<
c12d9c7d>] ? rtnl_fill_ifinfo+0x9bd/0xc70
[ 136.546400] [<
c11d6cae>] ? nla_parse+0x6e/0xb0
[ 136.546409] [<
c12db931>] rtnl_newlink+0x361/0x510
[ 136.546420] [<
c1023240>] ? vmalloc_sync_all+0x100/0x100
[ 136.546429] [<
c1362762>] ? error_code+0x5a/0x60
[ 136.546438] [<
c12db5d0>] ? rtnl_configure_link+0x80/0x80
[ 136.546446] [<
c12db27a>] rtnetlink_rcv_msg+0xfa/0x210
[ 136.546454] [<
c12db180>] ? __rtnl_unlock+0x20/0x20
[ 136.546463] [<
c12ee0fe>] netlink_rcv_skb+0x8e/0xb0
[ 136.546471] [<
c12daf1c>] rtnetlink_rcv+0x1c/0x30
[ 136.546479] [<
c12edafa>] netlink_unicast+0x23a/0x280
[ 136.546487] [<
c12ede6b>] netlink_sendmsg+0x26b/0x2f0
[ 136.546497] [<
c12bb828>] sock_sendmsg+0xc8/0x100
[ 136.546508] [<
c10adf61>] ? __alloc_pages_nodemask+0xe1/0x750
[ 136.546517] [<
c11d0602>] ? _copy_from_user+0x42/0x60
[ 136.546525] [<
c12c5e4c>] ? verify_iovec+0x4c/0xc0
[ 136.546534] [<
c12bd805>] sys_sendmsg+0x1c5/0x200
[ 136.546542] [<
c10c2150>] ? __do_fault+0x310/0x410
[ 136.546549] [<
c10c2c46>] ? do_wp_page+0x1d6/0x6b0
[ 136.546557] [<
c10c47d1>] ? handle_pte_fault+0xe1/0x720
[ 136.546565] [<
c12bd1af>] ? sys_getsockname+0x7f/0x90
[ 136.546574] [<
c10c4ec1>] ? handle_mm_fault+0xb1/0x180
[ 136.546582] [<
c1023240>] ? vmalloc_sync_all+0x100/0x100
[ 136.546589] [<
c10233b3>] ? do_page_fault+0x173/0x3d0
[ 136.546596] [<
c12bd87b>] ? sys_recvmsg+0x3b/0x60
[ 136.546605] [<
c12bdd83>] sys_socketcall+0x293/0x2d0
[ 136.546614] [<
c13629d0>] sysenter_do_call+0x12/0x26
[ 136.546619] Code: Bad EIP value.
[ 136.546627] EIP: [<
00000000>] 0x0 SS:ESP 0068:
f15c3b48
[ 136.546645] CR2:
0000000000000000
[ 136.546652] ---[ end trace
6909b560e78934fa ]---
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Thu, 26 May 2011 17:27:11 +0000 (17:27 +0000)]
inetpeer: fix race in unused_list manipulations
[ Upstream commit
686a7e32ca7fdd819eb9606abd3db52b77d1479f ]
Several crashes in cleanup_once() were reported in recent kernels.
Commit
d6cc1d642de9 (inetpeer: various changes) added a race in
unlink_from_unused().
One way to avoid taking unused_peers.lock before doing the list_empty()
test is to catch 0->1 refcnt transitions, using full barrier atomic
operations variants (atomic_cmpxchg() and atomic_inc_return()) instead
of previous atomic_inc() and atomic_add_unless() variants.
We then call unlink_from_unused() only for the owner of the 0->1
transition.
Add a new atomic_add_unless_return() static helper
With help from Arun Sharma.
Refs: https://bugzilla.kernel.org/show_bug.cgi?id=32772
Reported-by: Arun Sharma <asharma@fb.com>
Reported-by: Maximilian Engelhardt <maxi@daemonizer.de>
Reported-by: Yann Dupont <Yann.Dupont@univ-nantes.fr>
Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hans Schillstrom [Tue, 24 May 2011 12:11:05 +0000 (14:11 +0200)]
IPVS: bug in ip_vs_ftp, same list heaad used in all netns.
[ Upstream commit
c74c0bfe0b61cf41a897c2444c038e0d3f600556 ]
When ip_vs was adapted to netns the ftp application was not adapted
in a correct way.
However this is a fix to avoid kernel errors. In the long term another solution
might be chosen. I.e the ports that the ftp appl, uses should be per netns.
Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Thu, 26 May 2011 19:00:31 +0000 (15:00 -0400)]
bug.h: Move ratelimit warn interfaces to ratelimit.h
[ Upstream commit
86e4ca66e81bba0f8640f1fa19b8b8f72cbd0561 ]
As reported by Ingo Molnar, we still have configuration combinations
where use of the WARN_RATELIMIT interfaces break the build because
dependencies don't get met.
Instead of going down the long road of trying to make it so that
ratelimit.h can get included by kernel.h or asm-generic/bug.h,
just move the interface into ratelimit.h and make users have
to include that.
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Tue, 24 May 2011 20:15:41 +0000 (16:15 -0400)]
bug.h: Fix build with CONFIG_PRINTK disabled.
[ Upstream commit
6b3678354647a653e669746c05765f05d2b90239 ]
Based upon an email by Joe Perches.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Joe Perches [Sat, 21 May 2011 07:48:40 +0000 (07:48 +0000)]
net: filter: Use WARN_RATELIMIT
[ Upstream commit
6c4a5cb219520c7bc937ee186ca53f03733bd09f ]
A mis-configured filter can spam the logs with lots of stack traces.
Rate-limit the warnings and add printout of the bogus filter information.
Original-patch-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Joe Perches [Sat, 21 May 2011 07:48:39 +0000 (07:48 +0000)]
bug.h: Add WARN_RATELIMIT
[ Upstream commit
b3eec79b0776e5340a3db75b34953977c7e5086e ]
Add a generic mechanism to ratelimit WARN(foo, fmt, ...) messages
using a hidden per call site static struct ratelimit_state.
Also add an __WARN_RATELIMIT variant to be able to use a specific
struct ratelimit_state.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jozsef Kadlecsik [Tue, 24 May 2011 08:20:19 +0000 (10:20 +0200)]
netfilter: ipset: fix ip_set_flush return code
[ Upstream commit
9184a9cba622d9e38462ce11dff7da094b4fea84 ]
ip_set_flush returned -EPROTO instead of -IPSET_ERR_PROTOCOL, fixed
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jozsef Kadlecsik [Tue, 24 May 2011 08:20:18 +0000 (10:20 +0200)]
netfilter: ipset: remove unused variable from type_pf_tdel()
[ Upstream commit
b141c242ff978b63cdf0f3d1a767a5152750166b ]
Variable 'ret' is set in type_pf_tdel() but not used, remove.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Michał Mirosław [Thu, 26 May 2011 00:42:57 +0000 (00:42 +0000)]
net: fix ETHTOOL_SFEATURES compatibility with old ethtool_ops.set_flags
[ Upstream commit
fd0daf9d58f6b3342d07c5f6bbfb304dbe5db4ec ]
Current code squashes flags to bool - this makes set_flags fail whenever
some ETH_FLAG_* equivalent features are set. Fix this.
Signed-off-by: Micha©© Miros©©aw <mirq-linux@rere.qmqm.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jozsef Kadlecsik [Tue, 24 May 2011 08:20:17 +0000 (10:20 +0200)]
netfilter: ipset: Use proper timeout value to jiffies conversion
[ Upstream commit
249ddc79a38a8918ad53ac22606ca8af694344a5 ]
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Thu, 23 Jun 2011 22:06:00 +0000 (15:06 -0700)]
Linux 2.6.39.2
Stanislaw Gruszka [Wed, 8 Jun 2011 13:26:31 +0000 (15:26 +0200)]
iwlegacy: fix channel switch locking
commit
51e65257142a87fe46a1ce5c35c86c5baf012614 upstream.
We use priv->mutex to avoid race conditions between chswitch_done()
and mac_channel_switch(), when marking channel switch in
progress. But chswitch_done() can be called in atomic context
from rx_csa() or with mutex already taken from commit_rxon().
To fix remove mutex from chswitch_done() and use atomic bitops
for marking channel switch pending.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Thu, 2 Jun 2011 16:17:15 +0000 (18:17 +0200)]
iwlagn: fix channel switch locking
commit
6f213ff1919fab6f8244ceae55631b5d6ef750a7 upstream.
We use priv->mutex to avoid race conditions between iwl_chswitch_done()
and iwlagn_mac_channel_switch(), when marking channel switch in
progress. But iwl_chswitch_done() can be called in atomic context
from iwl_rx_csa() or with mutex already taken from iwlagn_commit_rxon().
These bugs were introduced by:
commit
79d07325502e73508f917475bc1617b60979dd94
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Thu May 6 08:54:11 2010 -0700
iwlwifi: support channel switch offload in driver
To fix remove mutex from iwl_chswitch_done() and use atomic bitops for
marking channel switch pending.
Also remove iwl2030_hw_channel_switch() since 2000 series adapters are
2.4GHz only devices.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wey-Yi Guy [Fri, 27 May 2011 15:40:24 +0000 (08:40 -0700)]
iwlagn: send tx power command if defer cause by RXON not match
commit
43e4e0b94984b45d52048e3ac027cac15c718b65 upstream.
During channge channel, tx power will not send to uCode, the tx power command
should send after scan complete. but should also can send after RXON command.
Stable fix identified by Stanislaw Gruszka <sgruszka@redhat.com>.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Namhyung Kim [Tue, 14 Jun 2011 04:20:19 +0000 (14:20 +1000)]
md/raid5: fix FUA request handling in ops_run_io()
commit
b062962edb086011e94ec4d9eb3f6a6d814f2a8f upstream.
Commit
e9c7469bb4f5 ("md: implment REQ_FLUSH/FUA support")
introduced R5_WantFUA flag and set rw to WRITE_FUA in that case.
However remaining code still checks whether rw is exactly same
as WRITE or not, so FUAed-write ends up with being treated as
READ. Fix it.
This bug has been present since 2.6.37 and the fix is suitable for any
-stable kernel since then. It is not clear why this has not caused
more problems.
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Namhyung Kim [Mon, 13 Jun 2011 05:48:22 +0000 (14:48 +0900)]
md/raid5: fix raid5_set_bi_hw_segments
commit
9b2dc8b665932a8e681a7ab3237f60475e75e161 upstream.
The @bio->bi_phys_segments consists of active stripes count in the
lower 16 bits and processed stripes count in the upper 16 bits. So
logical-OR operator should be bitwise one.
This bug has been present since 2.6.27 and the fix is suitable for any
-stable kernel since then. Fortunately the bad code is only used on
error paths and is relatively unlikely to be hit.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Namhyung Kim [Thu, 9 Jun 2011 01:42:54 +0000 (11:42 +1000)]
md: check ->hot_remove_disk when removing disk
commit
01393f3d5836b7d62e925e6f4658a7eb22b83a11 upstream.
Check pers->hot_remove_disk instead of pers->hot_add_disk in slot_store()
during disk removal. The linear personality only has ->hot_add_disk and
no ->hot_remove_disk, so that removing disk in the array resulted to
following kernel bug:
$ sudo mdadm --create /dev/md0 --level=linear --raid-devices=4 /dev/loop[0-3]
$ echo none | sudo tee /sys/block/md0/md/dev-loop2/slot
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
PGD
c9f5d067 PUD
8575a067 PMD 0
Oops: 0010 [#1] SMP
CPU 2
Modules linked in: linear loop bridge stp llc kvm_intel kvm asus_atk0110 sr_mod cdrom sg
Pid: 10450, comm: tee Not tainted 3.0.0-rc1-leonard+ #173 System manufacturer System Product Name/P5G41TD-M PRO
RIP: 0010:[<
0000000000000000>] [< (null)>] (null)
RSP: 0018:
ffff880085757df0 EFLAGS:
00010282
RAX:
ffffffffa00168e0 RBX:
ffff8800d1431800 RCX:
000000000000006e
RDX:
0000000000000001 RSI:
0000000000000002 RDI:
ffff88008543c000
RBP:
ffff880085757e48 R08:
0000000000000002 R09:
000000000000000a
R10:
0000000000000000 R11:
ffff88008543c2e0 R12:
00000000ffffffff
R13:
ffff8800b4641000 R14:
0000000000000005 R15:
0000000000000000
FS:
00007fe8c9e05700(0000) GS:
ffff88011fa00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
0000000000000000 CR3:
00000000b4502000 CR4:
00000000000406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process tee (pid: 10450, threadinfo
ffff880085756000, task
ffff8800c9f08000)
Stack:
ffffffff8138496a ffff8800b4641000 ffff88008543c268 0000000000000000
ffff8800b4641000 ffff88008543c000 ffff8800d1431868 ffffffff81a78a90
ffff8800b4641000 ffff88008543c000 ffff8800d1431800 ffff880085757e98
Call Trace:
[<
ffffffff8138496a>] ? slot_store+0xaa/0x265
[<
ffffffff81384bae>] rdev_attr_store+0x89/0xa8
[<
ffffffff8115a96a>] sysfs_write_file+0x108/0x144
[<
ffffffff81106b87>] vfs_write+0xb1/0x10d
[<
ffffffff8106e6c0>] ? trace_hardirqs_on_caller+0x111/0x135
[<
ffffffff81106cac>] sys_write+0x4d/0x77
[<
ffffffff814fe702>] system_call_fastpath+0x16/0x1b
Code: Bad RIP value.
RIP [< (null)>] (null)
RSP <
ffff880085757df0>
CR2:
0000000000000000
---[ end trace
ba5fc64319a826fb ]---
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tetsuo Handa [Mon, 13 Jun 2011 04:49:11 +0000 (13:49 +0900)]
TOMOYO: Fix oops in tomoyo_mount_acl().
commit
4e78c724d47e2342aa8fde61f6b8536f662f795f upstream.
In tomoyo_mount_acl() since 2.6.36, kern_path() was called without checking
dev_name != NULL. As a result, an unprivileged user can trigger oops by issuing
mount(NULL, "/", "ext3", 0, NULL) request.
Fix this by checking dev_name != NULL before calling kern_path(dev_name).
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dave Jones [Sun, 12 Jun 2011 20:35:28 +0000 (16:35 -0400)]
CPUFREQ: Remove cpufreq_stats sysfs entries on module unload.
commit
13f067537f34456443f61c950cd6dc37d1d5f3ee upstream.
cpufreq_stats leaves behind its sysfs entries, which causes a panic
when something stumbled across them.
(Discovered by unloading cpufreq_stats while powertop was loaded).
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Tue, 20 Jul 2010 12:34:50 +0000 (14:34 +0200)]
x86: cpu-hotplug: Prevent softirq wakeup on wrong CPU
commit
fd8a7de177b6f56a0fc59ad211c197a7df06b1ad upstream.
After a newly plugged CPU sets the cpu_online bit it enables
interrupts and goes idle. The cpu which brought up the new cpu waits
for the cpu_online bit and when it observes it, it sets the cpu_active
bit for this cpu. The cpu_active bit is the relevant one for the
scheduler to consider the cpu as a viable target.
With forced threaded interrupt handlers which imply forced threaded
softirqs we observed the following race:
cpu 0 cpu 1
bringup(cpu1);
set_cpu_online(smp_processor_id(), true);
local_irq_enable();
while (!cpu_online(cpu1));
timer_interrupt()
-> wake_up(softirq_thread_cpu1);
-> enqueue_on(softirq_thread_cpu1, cpu0);
^^^^
cpu_notify(CPU_ONLINE, cpu1);
-> sched_cpu_active(cpu1)
-> set_cpu_active((cpu1, true);
When an interrupt happens before the cpu_active bit is set by the cpu
which brought up the newly onlined cpu, then the scheduler refuses to
enqueue the woken thread which is bound to that newly onlined cpu on
that newly onlined cpu due to the not yet set cpu_active bit and
selects a fallback runqueue. Not really an expected and desirable
behaviour.
So far this has only been observed with forced hard/softirq threading,
but in theory this could happen without forced threaded hard/softirqs
as well. It's probably unobservable as it would take a massive
interrupt storm on the newly onlined cpu which causes the softirq loop
to wake up the softirq thread and an even longer delay of the cpu
which waits for the cpu_online bit.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Florian Fainelli [Mon, 6 Jun 2011 08:15:49 +0000 (10:15 +0200)]
x86: devicetree: Add missing early_init_dt_setup_initrd_arch stub
commit
977cb76d52e7aa040e18a84b29fe6fd80d79319b upstream.
This patch fixes the following build failure:
drivers/built-in.o: In function `early_init_dt_check_for_initrd':
/home/florian/dev/kernel/x86/linux-2.6-x86/drivers/of/fdt.c:571:
undefined reference to `early_init_dt_setup_initrd_arch'
make: *** [.tmp_vmlinux1] Error 1
which happens as soon as we enable initrd support on a x86 devicetree
platform such as Intel CE4100.
Signed-off-by: Florian Fainelli <ffainelli@freebox.fr>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Maxime Bizon <mbizon@freebox.fr>
Acked-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Link: http://lkml.kernel.org/r/201106061015.50039.ffainelli@freebox.fr
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Johannes Berg [Wed, 8 Jun 2011 11:27:29 +0000 (13:27 +0200)]
mac80211: fix IBSS teardown race
commit
f3209bea110cade12e2b133da8b8499689cb0e2e upstream.
Ignacy reports that sometimes after leaving an IBSS
joining a new one didn't work because there still
were stations on the list. He fixed it by flushing
stations when attempting to join a new IBSS, but
this shouldn't be happening in the first case. When
I looked into it I saw a race condition in teardown
that could cause stations to be added after flush,
and thus cause this situation. Ignacy confirms that
after applying my patch he hasn't seen this happen
again.
Reported-by: Ignacy Gawedzki <i@lri.fr>
Debugged-by: Ignacy Gawedzki <i@lri.fr>
Tested-by: Ignacy Gawedzki <i@lri.fr>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Williams, Mitch A [Tue, 7 Jun 2011 21:22:57 +0000 (14:22 -0700)]
igb: fix i350 SR-IOV failture
commit
665c8c8ee405738375b679246b49342ce38ba056 upstream.
When SR-IOV is enabled, i350 devices fail to pass traffic. This is due to
the driver attempting to enable RSS on the PF device, which is not
supported by the i350.
When max_vfs is specified on an i350 adapter, set the number of RSS queues
to 1.
This issue affects 2.6.39 as well.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@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>
Stanislaw Gruszka [Mon, 6 Jun 2011 13:11:30 +0000 (15:11 +0200)]
iwl4965: set tx power after rxon_assoc
commit
51892dbbd511911c0f965a36b431fc3e8f1e4f8a upstream.
Setting tx power can be deferred during scan or changing channel.
If after that correct tx power settings will not be sent to device,
we can observe transmission problems and timeouts. Force to send
tx power settings also after partial rxon change, to assure device
always be configured with up-to-date settings.
Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=36492
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Thu, 26 May 2011 15:14:22 +0000 (17:14 +0200)]
iwlagn: use cts-to-self protection on 5000 adapters series
commit
42b70a5f6d18165a075d189d1bee82fad7cdbf29 upstream.
This patch fixes 802.11n stability and performance regression we have
since 2.6.35. It boost performance on my 5GHz N-only network from about
5MB/s to 8MB/s. Similar percentage boost can be observed on 2.4 GHz.
These are test results of 5x downloading of approximately 700MB iso
image:
vanilla: 5.27 5.22 4.94 4.47 5.31 ; avr 5.0420 std 0.35110
patched: 8.07 7.95 8.06 7.99 7.96 ; avr 8.0060 std 0.055946
This was achieved with NetworkManager configured to do not perform
periodical scans, by configuring constant BSSID. With periodical scans,
after some time, performance downgrade to unpatched driver level, like
in example below:
patched: 7.40 7.61 4.28 4.37 4.80 avr 5.6920 std 1.6683
However patch still make better here, since similar test on unpatched
driver make link disconnects with below messages after some time:
wlan1: authenticate with 00:23:69:35:d1:3f (try 1)
wlan1: authenticate with 00:23:69:35:d1:3f (try 2)
wlan1: authenticate with 00:23:69:35:d1:3f (try 3)
wlan1: authentication with 00:23:69:35:d1:3f timed out
On 2.6.35 kernel patch helps against connection hangs with messages:
iwlagn 0000:20:00.0: queue 10 stuck 3 time. Fw reload.
iwlagn 0000:20:00.0: On demand firmware reload
iwlagn 0000:20:00.0: Stopping AGG while state not ON or starting
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marek Olšák [Fri, 10 Jun 2011 14:41:26 +0000 (14:41 +0000)]
drm/radeon/kms: do bounds checking for 3D_LOAD_VBPNTR and bump array limit
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>
Robert Richter [Tue, 31 May 2011 10:35:41 +0000 (12:35 +0200)]
oprofile, dcookies: Fix possible circular locking dependency
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>
Robert Richter [Thu, 26 May 2011 16:39:35 +0000 (18:39 +0200)]
oprofile: Fix locking dependency in sync_start()
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>
Robert Richter [Thu, 26 May 2011 16:22:54 +0000 (18:22 +0200)]
oprofile: Free potentially owned tasks in case of errors
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>
Daniel T Chen [Mon, 6 Jun 2011 22:55:34 +0000 (18:55 -0400)]
ALSA: hda: Fix quirk for Dell Inspiron 910
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>
Sangbeom Kim [Fri, 10 Jun 2011 01:36:54 +0000 (10:36 +0900)]
ASoC: SAMSUNG: Fix the incorrect referencing of I2SCON register
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>
Lars-Peter Clausen [Thu, 9 Jun 2011 11:22:36 +0000 (13:22 +0200)]
ASoC: snd_soc_new_{mixer,mux,pga} make sure to use right DAPM context
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>
Mark Brown [Wed, 8 Jun 2011 17:07:49 +0000 (18:07 +0100)]
ASoC: WM8804 does not support sample rates below 32kHz
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>
Mark Brown [Tue, 7 Jun 2011 22:42:04 +0000 (23:42 +0100)]
ASoC: Fix WM8962 headphone volume update for use of advanced caches
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>
Lars-Peter Clausen [Mon, 6 Jun 2011 11:38:35 +0000 (13:38 +0200)]
ASoC: AD1836: Fix setting the PCM format
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>
Jeff Layton [Fri, 10 Jun 2011 20:14:57 +0000 (16:14 -0400)]
cifs: don't allow cifs_reconnect to exit with NULL socket pointer
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>
John Johansen [Wed, 8 Jun 2011 22:07:47 +0000 (15:07 -0700)]
AppArmor: Fix sleep in invalid context from task_setrlimit
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>
Dmitry Torokhov [Tue, 31 May 2011 21:37:23 +0000 (14:37 -0700)]
USB: xhci - fix interval calculation for FS isoc endpoints
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>
Sarah Sharp [Thu, 2 Jun 2011 18:33:02 +0000 (11:33 -0700)]
xhci: Disable MSI for some Fresco Logic hosts.
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>
Maarten Lankhorst [Wed, 1 Jun 2011 21:27:50 +0000 (23:27 +0200)]
xhci: Do not issue device reset when device is not setup
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>
Maarten Lankhorst [Wed, 1 Jun 2011 21:27:49 +0000 (23:27 +0200)]
xhci: Add defines for hardcoded slot states
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>
Greg Kroah-Hartman [Fri, 10 Jun 2011 23:49:10 +0000 (16:49 -0700)]
Revert "x86, efi: Retain boot service code until after switching to virtual 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>
Alan Stern [Tue, 7 Jun 2011 15:35:52 +0000 (11:35 -0400)]
usb-storage: redo incorrect reads
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>
Steffen Sledz [Tue, 7 Jun 2011 12:01:56 +0000 (14:01 +0200)]
USB: serial: add another 4N-GALAXY.DE PID to ftdi_sio driver
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>
Libor Pechacek [Fri, 20 May 2011 12:53:25 +0000 (14:53 +0200)]
USB: core: Tolerate protocol stall during hub and port status read
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>
Greg Kroah-Hartman [Tue, 7 Jun 2011 22:03:37 +0000 (15:03 -0700)]
Revert "USB: option: add ID for ZTE MF 330"
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>
Torsten Hilbrich [Mon, 6 Jun 2011 13:39:55 +0000 (15:39 +0200)]
USB: option Add blacklist for ZTE K3765-Z (19d2:2002)
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>
Dan Williams [Mon, 6 Jun 2011 21:55:41 +0000 (16:55 -0500)]
option: add Prolink PH300 modem IDs
commit
5c3e4076ee8253c1e3688d10653ddee47a03b0db upstream.
Simple ID addition.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Williams [Mon, 6 Jun 2011 21:22:44 +0000 (16:22 -0500)]
option: add Alcatel X200 to sendsetup blacklist
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>
Dan Williams [Mon, 6 Jun 2011 21:08:39 +0000 (16:08 -0500)]
option: add Zoom 4597 modem USB IDs
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>
Mathias Krause [Thu, 9 Jun 2011 18:05:18 +0000 (20:05 +0200)]
exec: delay address limit change until point of no return
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>
Michael Chang [Mon, 30 May 2011 06:28:25 +0000 (14:28 +0800)]
staging: gma500: get control from firmware framebuffer if conflicts
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>
Toby Gray [Mon, 6 Jun 2011 13:52:48 +0000 (14:52 +0100)]
USB: cdc-acm: Adding second ACM channel support for Nokia E7 and C7
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>
Joerg Roedel [Mon, 6 Jun 2011 14:50:14 +0000 (16:50 +0200)]
x86/amd-iommu: Fix boot crash with hidden PCI devices
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>
Joerg Roedel [Mon, 6 Jun 2011 14:04:02 +0000 (16:04 +0200)]
x86/amd-iommu: Fix 3 possible endless loops
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>
Joerg Roedel [Mon, 30 May 2011 13:56:24 +0000 (15:56 +0200)]
x86/amd-iommu: Use only per-device dma_ops
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>
Laurent Pinchart [Mon, 30 May 2011 18:45:47 +0000 (15:45 -0300)]
media: Fix media device minor registration
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>
Jeff Layton [Mon, 6 Jun 2011 19:40:23 +0000 (15:40 -0400)]
cifs: silence printk when establishing first session on socket
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>
Linus Walleij [Tue, 31 May 2011 16:14:39 +0000 (18:14 +0200)]
genirq: Fix descriptor init on non-sparse IRQs
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>
Bruno Prémont [Tue, 24 May 2011 19:59:17 +0000 (19:59 +0000)]
video: Fix use-after-free by vga16fb on rmmod
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>
Dan Carpenter [Fri, 3 Jun 2011 04:45:28 +0000 (07:45 +0300)]
xen: off by one errors in multicalls.c
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>
OGAWA Hirofumi [Tue, 31 May 2011 10:38:07 +0000 (19:38 +0900)]
fat: Fix corrupt inode flags when remove ATTR_SYS flag
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>
Daniel Haid [Wed, 8 Jun 2011 10:04:45 +0000 (20:04 +1000)]
drm/radeon/kms: fix for radeon on systems >4GB without hardware iommu
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>
Alex Deucher [Fri, 27 May 2011 14:05:03 +0000 (10:05 -0400)]
drm/radeon/kms: viewport height has to be even
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>
Hans de Goede [Sat, 4 Jun 2011 13:39:21 +0000 (15:39 +0200)]
drm/i915: Add a no lvds quirk for the Asus EeeBox PC EB1007
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>
Peter Zijlstra [Mon, 6 Jun 2011 10:32:43 +0000 (12:32 +0200)]
lockdep: Fix lock_is_held() on recursion
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>
Stefan Metzmacher [Wed, 1 Jun 2011 02:01:41 +0000 (02:01 +0000)]
usbnet/cdc_ncm: add missing .reset_resume hook
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>
Jens Axboe [Fri, 27 May 2011 05:44:43 +0000 (07:44 +0200)]
block: export blk_{get,put}_queue()
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>
Luciano Coelho [Wed, 18 May 2011 21:43:38 +0000 (00:43 +0300)]
nl80211: fix check for valid SSID size in scan operations
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>
Joe Perches [Tue, 29 Mar 2011 22:21:32 +0000 (15:21 -0700)]
asus-wmi: Remove __init from asus_wmi_platform_init
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>