phc [Tue, 28 Jun 2011 11:33:25 +0000 (19:33 +0800)]
RK29SmartPhone:SDK board does not have bp_ap_wakeup GPIO, so add judge here before use the GPIO
hhb [Tue, 28 Jun 2011 09:23:43 +0000 (17:23 +0800)]
rk29:UART->add new uart driver and it is default used, but you can use the old driver by setting the menuconfig
黄涛 [Tue, 28 Jun 2011 09:00:04 +0000 (17:00 +0800)]
pack-kernel.sh: exclude newton board, add phone sdk
黄涛 [Tue, 28 Jun 2011 08:27:10 +0000 (16:27 +0800)]
Staging: dream: Kconfig fix for non-HTC hardware
zyw [Tue, 28 Jun 2011 07:43:00 +0000 (15:43 +0800)]
fix cursor reload bug
邱建斌 [Tue, 28 Jun 2011 06:50:19 +0000 (14:50 +0800)]
rk29_phone: headset hook key update
chenli [Tue, 28 Jun 2011 06:39:32 +0000 (14:39 +0800)]
rk29 IPP:IPP driver provides synchronous and asynchronous call interfaces.
1.In the case of synchronous call please use ipp_blit_sync function.
In the case of asynchronous call please use ipp_blit_async function.
The old interface ipp_do_blit is obsolete!
2.Use ipp_blit_sync instead of ipp_do_blit in rk29_fb.c and rk29_camera_oneframe.c.
3.Translate the Chinese commets into English.
xsf@rock-chips.com [Tue, 28 Jun 2011 03:50:02 +0000 (11:50 +0800)]
A22:switch to 32k when sleep
邱建斌 [Tue, 28 Jun 2011 02:32:21 +0000 (10:32 +0800)]
rk29_phone: fix hook key irq. if headset have not hook key then not reported keydown
chenli [Tue, 28 Jun 2011 01:58:29 +0000 (09:58 +0800)]
rk29 IPP:IPP driver provides synchronous and asynchronous call interfaces.
1.In case of synchronous call please use ipp_blit_sync function.
In case of asynchronous call please use ipp_blit_async function.
The old interface ipp_do_blit is not recommended from now on.
2.Use ipp_blit_sync instead of ipp_do_blit in rk29_fb.c
黄涛 [Tue, 28 Jun 2011 01:47:32 +0000 (09:47 +0800)]
Merge remote-tracking branch 'linux-2.6.32.y/master' into develop
Merge Linux 2.6.32.42
Conflicts:
Makefile
drivers/net/wireless/iwlwifi/iwl-5000.c
drivers/net/wireless/p54/p54usb.c
phc [Mon, 27 Jun 2011 12:38:56 +0000 (20:38 +0800)]
RK29SmartPhone:open 32K crystalloid default
xsf@rock-chips.com [Mon, 27 Jun 2011 12:18:27 +0000 (20:18 +0800)]
RK29SmartPhone:switch to 32k when sleep
黄涛 [Mon, 27 Jun 2011 11:00:30 +0000 (19:00 +0800)]
rk29: ddr3sdk: cpufreq support 1G Hz
黄涛 [Mon, 27 Jun 2011 09:59:38 +0000 (17:59 +0800)]
Revert "rk29:UART->add new uart driver rk_serial.c which can be configurated in menuconfig,but the old driver is default used"
This reverts commit
ee1cd711356b310f047bd18a2d26fb9a8987430f.
hhb [Mon, 27 Jun 2011 09:40:18 +0000 (17:40 +0800)]
rk29:UART->add new uart driver rk_serial.c which can be configurated in menuconfig,but the old driver is default used
hhb [Fri, 24 Jun 2011 07:00:49 +0000 (15:00 +0800)]
rk29:touch screen -> modify tp suspend and resume function which would really work
root [Mon, 27 Jun 2011 08:47:30 +0000 (16:47 +0800)]
phonesdk: modify ARM freq and core voltage in running
黄涛 [Mon, 27 Jun 2011 06:16:12 +0000 (14:16 +0800)]
rk29: vivante: alloc_pages add GFP_DMA flag to support 1G memory
黄涛 [Mon, 27 Jun 2011 05:57:32 +0000 (13:57 +0800)]
rk29: Kconfig: support 1G memory
黄涛 [Mon, 27 Jun 2011 05:25:19 +0000 (13:25 +0800)]
rk29: phonepadsdk: support 1G memory
黄涛 [Mon, 27 Jun 2011 05:24:27 +0000 (13:24 +0800)]
rk29: phonesdk: support 1G memory
黄涛 [Mon, 27 Jun 2011 05:24:12 +0000 (13:24 +0800)]
rk29: rk29-ddr3sdk: support 1G memory
黄涛 [Mon, 27 Jun 2011 05:23:52 +0000 (13:23 +0800)]
rk29: rk29sdk: support 1G memory
黄涛 [Mon, 27 Jun 2011 05:14:38 +0000 (13:14 +0800)]
rk29: vivante: fix computation of resource size for 1G memory
黄涛 [Mon, 27 Jun 2011 05:06:52 +0000 (13:06 +0800)]
rk29: mmu.c: enlarge vmalloc_reserve to support 1G memory
黄涛 [Mon, 27 Jun 2011 05:01:05 +0000 (13:01 +0800)]
rk29: memory.h: fix for highmem
黄涛 [Mon, 27 Jun 2011 05:00:24 +0000 (13:00 +0800)]
rk29: rk29_iomap.h: set RK29_SDRAM_PHYS to 0x60000000U, fix gcc warning: integer overflow in expression
蔡枫 [Mon, 27 Jun 2011 03:48:04 +0000 (11:48 +0800)]
add 5 point touch, close cs42l52 log for newton
蔡枫 [Sat, 25 Jun 2011 14:42:44 +0000 (22:42 +0800)]
Merge branch 'develop' of 10.10.10.29:/home/rockchip/kernel into develop
蔡枫 [Sat, 25 Jun 2011 14:42:23 +0000 (22:42 +0800)]
fix tp and codec bug in newton board
phc [Sat, 25 Jun 2011 08:43:26 +0000 (16:43 +0800)]
RK29SmartPhone:23d IMEI read support
蔡枫 [Fri, 24 Jun 2011 14:40:11 +0000 (22:40 +0800)]
Merge branch 'develop' of 10.10.10.29:/home/rockchip/kernel into develop
蔡枫 [Fri, 24 Jun 2011 14:39:48 +0000 (22:39 +0800)]
add support for newton board
yangkai [Fri, 24 Jun 2011 10:09:34 +0000 (18:09 +0800)]
fix kernel panic when not standard usb keyboard connect
yangkai [Fri, 24 Jun 2011 08:13:40 +0000 (16:13 +0800)]
revert ddr v2.02 and dpll use high band
xsf@rock-chips.com [Fri, 24 Jun 2011 07:43:10 +0000 (15:43 +0800)]
A22: make wm8310 exit suspend
yangkai [Fri, 24 Jun 2011 06:57:35 +0000 (14:57 +0800)]
adjust usb controller init sequence and remove some log
phc [Fri, 24 Jun 2011 06:39:39 +0000 (14:39 +0800)]
RK29SmartPhone:TP change from GT801 to GT818
黄涛 [Fri, 24 Jun 2011 04:13:19 +0000 (12:13 +0800)]
rk29: cru.h: fix SOFT_RST_HSADC define bug
hhb [Fri, 24 Jun 2011 02:27:56 +0000 (10:27 +0800)]
rk29:add rk29_dma_config(dws->rx_dmach, 1, 1) one more argument
Greg Kroah-Hartman [Thu, 23 Jun 2011 22:24:26 +0000 (15:24 -0700)]
Linux 2.6.32.42
Greg Kroah-Hartman [Wed, 15 Jun 2011 20:12:35 +0000 (13:12 -0700)]
Revert "iwlagn: Support new 5000 microcode."
This reverts commit
6f63415fc1b690cb50c2ad48ba6e9e6e88e271b4.
It turns out this is not what we want to have happen for the .32 and
.33-longterm kernels as it does not work properly at all.
This was reported by Gentoo, Arch, and Canonical developers as causing
problems for their users:
https://bugs.archlinux.org/task/24302
http://bugs.gentoo.org/show_bug.cgi?id=359445
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796336
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Cc: Gordon Malm <gengor@gentoo.org>
Cc: Don Fry <donald.h.fry@intel.com>
Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kasper Pedersen [Wed, 20 Oct 2010 22:55:15 +0000 (15:55 -0700)]
time: Compensate for rounding on odd-frequency clocksources
commit
a386b5af8edda1c742ce9f77891e112eefffc005 upstream.
When the clocksource is not a multiple of HZ, the clock will be off. For
acpi_pm, HZ=1000 the error is 127.111 ppm:
The rounding of cycle_interval ends up generating a false error term in
ntp_error accumulation since xtime_interval is not exactly 1/HZ. So, we
subtract out the error caused by the rounding.
This has been visible since 2.6.32-rc2
commit
a092ff0f90cae22b2ac8028ecd2c6f6c1a9e4601
time: Implement logarithmic time accumulation
That commit raised NTP_INTERVAL_FREQ and exposed the rounding error.
testing tool: http://n1.taur.dk/permanent/testpmt.c
Also tested with ntpd and a frequency counter.
Signed-off-by: Kasper Pedersen <kkp2010@kasperkp.dk>
Acked-by: john stultz <johnstul@us.ibm.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Will Tisdale <willtisdale@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Sat, 5 Feb 2011 20:08:59 +0000 (20:08 +0000)]
xen: Use IRQF_FORCE_RESUME
commit
676dc3cf5bc36a9e129a3ad8fe3bd7b2ebf20f5d upstream.
Mark the IRQF_NO_SUSPEND interrupts IRQF_FORCE_RESUME and remove the extra
walk through the interrupt descriptors.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Fri, 4 Feb 2011 12:19:20 +0000 (13:19 +0100)]
genirq: Add IRQF_FORCE_RESUME
commit
dc5f219e88294b93009eef946251251ffffb6d60 upstream.
Xen needs to reenable interrupts which are marked IRQF_NO_SUSPEND in the
resume path. Add a flag to force the reenabling in the resume code.
Tested-and-acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ian Campbell [Mon, 1 Nov 2010 16:30:09 +0000 (16:30 +0000)]
xen: events: do not unmask event channels on resume
commit
6903591f314b8947d0e362bda7715e90eb9df75e upstream.
The IRQ core code will take care of disabling and reenabling
interrupts over suspend resume automatically, therefore we do not need
to do this in the Xen event channel code.
The only exception is those event channels marked IRQF_NO_SUSPEND
which the IRQ core ignores. We must unmask these ourselves, taking
care to obey the current IRQ_DISABLED status. Failure check for
IRQ_DISABLED leads to enabling polled only event channels, such as
that associated with the pv spinlocks, which must never be enabled:
[ 21.970432] ------------[ cut here ]------------
[ 21.970432] kernel BUG at arch/x86/xen/spinlock.c:343!
[ 21.970432] invalid opcode: 0000 [#1] SMP
[ 21.970432] last sysfs file: /sys/devices/virtual/net/lo/operstate
[ 21.970432] Modules linked in:
[ 21.970432]
[ 21.970432] Pid: 0, comm: swapper Not tainted (2.6.32.24-x86_32p
-xen-01034-g787c727 #34)
[ 21.970432] EIP: 0061:[<
c102e209>] EFLAGS:
00010046 CPU: 3
[ 21.970432] EIP is at dummy_handler+0x3/0x7
[ 21.970432] EAX:
0000021c EBX:
dfc16880 ECX:
0000001a EDX:
00000000
[ 21.970432] ESI:
dfc02c00 EDI:
00000001 EBP:
dfc47e10 ESP:
dfc47e10
[ 21.970432] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
[ 21.970432] Process swapper (pid: 0, ti=
dfc46000 task=
dfc39440 task.ti=
dfc46000)
[ 21.970432] Stack:
[ 21.970432]
dfc47e30 c10a39f0 0000021c 00000000 00000000 dfc16880 0000021c 00000001
[ 21.970432] <0>
dfc47e40 c10a4f08 0000021c 00000000 dfc47e78 c12240a7 c1839284 c1839284
[ 21.970432] <0>
00000200 00000000 00000000 f5720000 c1f3d028 c1f3d02c 00000180 dfc47e90
[ 21.970432] Call Trace:
[ 21.970432] [<
c10a39f0>] ? handle_IRQ_event+0x5f/0x122
[ 21.970432] [<
c10a4f08>] ? handle_percpu_irq+0x2f/0x55
[ 21.970432] [<
c12240a7>] ? __xen_evtchn_do_upcall+0xdb/0x15f
[ 21.970432] [<
c122481e>] ? xen_evtchn_do_upcall+0x20/0x30
[ 21.970432] [<
c1030d47>] ? xen_do_upcall+0x7/0xc
[ 21.970432] [<
c102007b>] ? apic_reg_read+0xd3/0x22d
[ 21.970432] [<
c1002227>] ? hypercall_page+0x227/0x1005
[ 21.970432] [<
c102d30b>] ? xen_force_evtchn_callback+0xf/0x14
[ 21.970432] [<
c102da7c>] ? check_events+0x8/0xc
[ 21.970432] [<
c102da3b>] ? xen_irq_enable_direct_end+0x0/0x1
[ 21.970432] [<
c105e485>] ? finish_task_switch+0x62/0xba
[ 21.970432] [<
c14e3f84>] ? schedule+0x808/0x89d
[ 21.970432] [<
c1084dc5>] ? hrtimer_start_expires+0x1a/0x22
[ 21.970432] [<
c1085154>] ? tick_nohz_restart_sched_tick+0x15a/0x162
[ 21.970432] [<
c102f43a>] ? cpu_idle+0x6d/0x6f
[ 21.970432] [<
c14db29e>] ? cpu_bringup_and_idle+0xd/0xf
[ 21.970432] Code: 5d 0f 95 c0 0f b6 c0 c3 55 66 83 78 02 00 89 e5 5d 0f 95 \
c0 0f b6 c0 c3 55 b2 01 86 10 31 c0 84 d2 89 e5 0f 94 c0 5d c3 55 89 e5 <0f> 0b \
eb fe 55 80 3d 4c ce 84 c1 00 89 e5 57 56 89 c6 53 74 15
[ 21.970432] EIP: [<
c102e209>] dummy_handler+0x3/0x7 SS:ESP 0069:
dfc47e10
[ 21.970432] ---[ end trace
c0b71f7e12cf3011 ]---
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fernando Luis Vazquez Cao [Tue, 10 May 2011 08:00:21 +0000 (10:00 +0200)]
netfilter: IPv6: fix DSCP mangle code
commit
1ed2f73d90fb49bcf5704aee7e9084adb882bfc5 upstream.
The mask indicates the bits one wants to zero out, so it needs to be
inverted before applying to the original TOS field.
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fernando Luis Vazquez Cao [Tue, 10 May 2011 07:55:44 +0000 (09:55 +0200)]
netfilter: IPv6: initialize TOS field in REJECT target module
commit
4319cc0cf5bb894b7368008cdf6dd20eb8868018 upstream.
The IPv6 header is not zeroed out in alloc_skb so we must initialize
it properly unless we want to see IPv6 packets with random TOS fields
floating around. The current implementation resets the flow label
but this could be changed if deemed necessary.
We stumbled upon this issue when trying to apply a mangle rule to
the RST packet generated by the REJECT target module.
Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
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>
Johannes Weiner [Fri, 1 Oct 2010 07:43:54 +0000 (07:43 +0000)]
xfs: properly account for reclaimed inodes
commit
081003fff467ea0e727f66d5d435b4f473a789b3 upstream.
When marking an inode reclaimable, a per-AG counter is increased, the
inode is tagged reclaimable in its per-AG tree, and, when this is the
first reclaimable inode in the AG, the AG entry in the per-mount tree
is also tagged.
When an inode is finally reclaimed, however, it is only deleted from
the per-AG tree. Neither the counter is decreased, nor is the parent
tree's AG entry untagged properly.
Since the tags in the per-mount tree are not cleared, the inode
shrinker iterates over all AGs that have had reclaimable inodes at one
point in time.
The counters on the other hand signal an increasing amount of slab
objects to reclaim. Since "
70e60ce xfs: convert inode shrinker to
per-filesystem context" this is not a real issue anymore because the
shrinker bails out after one iteration.
But the problem was observable on a machine running v2.6.34, where the
reclaimable work increased and each process going into direct reclaim
eventually got stuck on the xfs inode shrinking path, trying to scan
several million objects.
Fix this by properly unwinding the reclaimable-state tracking of an
inode when it is reclaimed.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>
Backported-by: Stefan Priebe <s.priebe@profihost.ag>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bjorn Helgaas [Wed, 24 Mar 2010 16:44:33 +0000 (10:44 -0600)]
ACPI: use _HID when supplied by root-level devices
commit
b7b30de53aef6ce773d34837ba7d8422bd3baeec upstream.
Previously, we assumed the only Device object immediately below the root
was the \_SB Scope (which the ACPI CA treats as a Device), so we forced
the HID of all such objects to ACPI_BUS_HID ("LNXSYBUS").
However, there are DSDTs that supply root-level Device objects with _HIDs.
This patch makes us pay attention to those _HIDs and only add the synthetic
ACPI_BUS_HID for root-level objects that do not supply their own _HID.
For example, this DSDT: https://bugzilla.kernel.org/show_bug.cgi?id=15605
contains:
Scope (_SB) {
...
}
Device (AMW0) {
Name (_HID, EisaId ("PNP0C14"))
...
}
and we should use "PNP0C14" for the AMW0 device, not "LNXSYBUS".
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Yong Wang <yong.y.wang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Tested-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
James Bottomley [Sun, 24 Apr 2011 19:30:14 +0000 (14:30 -0500)]
pata_cm64x: fix boot crash on parisc
commit
9281b16caac1276817b77033c5b8a1f5ca30102c upstream.
The old IDE cmd64x checks the status of the CNTRL register to see if
the ports are enabled before probing them. pata_cmd64x doesn't do
this, which causes a HPMC on parisc when it tries to poke at the
secondary port because apparently the BAR isn't wired up (and a
non-responding piece of memory causes a HPMC).
Fix this by porting the CNTRL register port detection logic from IDE
cmd64x. In addition, following converns from Alan Cox, add a check to
see if a mobility electronics bridge is the immediate parent and forgo
the check if it is (prevents problems on hotplug controllers).
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bartlomiej Zolnierkiewicz [Mon, 18 Jan 2010 17:15:18 +0000 (18:15 +0100)]
pata_cmd64x: remove unused definitions
commit
c754d9b6e04371fb398cdd2f5e77be895126be20 upstream.
s/ARTIM2/ARTTIM23/ in cmd648_bmdma_stop() while at it
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bartlomiej Zolnierkiewicz [Mon, 18 Jan 2010 17:15:11 +0000 (18:15 +0100)]
pata_cmd64x: cmd648_bmdma_stop() fix
commit
03a849e6ddb604ff6a220b78637ee8e122ffc796 upstream.
Clear the primary channel pending interrupt bit
instead of the reserved one.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bartlomiej Zolnierkiewicz [Mon, 18 Jan 2010 17:14:55 +0000 (18:14 +0100)]
pata_cmd64x: fix PIO setup
commit
a2bd62207af4be8f5fe815ff90cc309056407829 upstream.
Fix incorrect handling of recovery clocks value == 16 resulting
in overclocked recovery timings & potentially underclocked active
timings.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sergei Shtylyov [Tue, 24 Nov 2009 18:54:49 +0000 (22:54 +0400)]
ata: use pci_dev->revision
commit
89d3b3603bfb648e0113d8682d4f84dd18a776bd upstream.
Some places were using PCI_CLASS_REVISION instead of PCI_REVISION_ID, so
they weren't converted by commit
44c10138fd4bbc4b6d6bff0873c24902f2a9da65
(PCI: Change all drivers to use pci_device->revision).
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.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>
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>
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>
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>
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>
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>
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: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>
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>
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>
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>
Jordan_Hargrave@Dell.com [Mon, 9 May 2011 20:24:55 +0000 (15:24 -0500)]
PCI: Set PCIE maxpayload for card during hotplug insertion
commit
e522a7126c7c144a1dd14c6f217ac31e71082b1d upstream.
The following patch sets the MaxPayload setting to match the parent
reading when inserting a PCIE card into a hotplug slot. On our system,
the upstream bridge is set to 256, but when inserting a card, the card
setting defaults to 128. As soon as I/O is performed to the card it
starts receiving errors since the payload size is too small.
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hugh Dickins [Mon, 6 Jun 2011 05:03:13 +0000 (22:03 -0700)]
mm: fix ENOSPC returned by handle_mm_fault()
commit
e0dcd8a05be438b3d2e49ef61441ea3a463663f8 upstream.
Al Viro observes that in the hugetlb case, handle_mm_fault() may return
a value of the kind ENOSPC when its caller is expecting a value of the
kind VM_FAULT_SIGBUS: fix alloc_huge_page()'s failure returns.
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: 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>
James Bottomley [Wed, 25 May 2011 20:52:14 +0000 (15:52 -0500)]
Fix oops caused by queue refcounting failure
commit
e73e079bf128d68284efedeba1fbbc18d78610f9 upstream.
In certain circumstances, we can get an oops from a torn down device.
Most notably this is from CD roms trying to call scsi_ioctl. The root
cause of the problem is the fact that after scsi_remove_device() has
been called, the queue is fully torn down. This is actually wrong
since the queue can be used until the sdev release function is called.
Therefore, we add an extra reference to the queue which is released in
sdev->release, so the queue always exists.
Reported-by: Parag Warudkar <parag.lkml@gmail.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
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>
Namhyung Kim [Sat, 28 May 2011 12:44:46 +0000 (14:44 +0200)]
nbd: limit module parameters to a sane value
commit
3b2710824e00d238554c13b5add347e6c701ab1a upstream.
The 'max_part' parameter controls the number of maximum partition
a nbd device can have. However if a user specifies very large
value it would exceed the limitation of device minor number and
can cause a kernel oops (or, at least, produce invalid device
nodes in some cases).
In addition, specifying large 'nbds_max' value causes same
problem for the same reason.
On my desktop, following command results to the kernel bug:
$ sudo modprobe nbd max_part=100000
kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/block/nbd4/range
CPU 1
Modules linked in: nbd(+) bridge stp llc kvm_intel kvm asus_atk0110 sg sr_mod cdrom
Pid: 2522, comm: modprobe Tainted: G W 2.6.39-leonard+ #159 System manufacturer System Product Name/P5G41TD-M PRO
RIP: 0010:[<
ffffffff8115aa08>] [<
ffffffff8115aa08>] internal_create_group+0x2f/0x166
RSP: 0018:
ffff8801009f1de8 EFLAGS:
00010246
RAX:
00000000ffffffef RBX:
ffff880103920478 RCX:
00000000000a7bd3
RDX:
ffffffff81a2dbe0 RSI:
0000000000000000 RDI:
ffff880103920478
RBP:
ffff8801009f1e38 R08:
ffff880103920468 R09:
ffff880103920478
R10:
ffff8801009f1de8 R11:
ffff88011eccbb68 R12:
ffffffff81a2dbe0
R13:
ffff880103920468 R14:
0000000000000000 R15:
ffff880103920400
FS:
00007f3c49de9700(0000) GS:
ffff88011f800000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
00007f3b7fe7c000 CR3:
00000000cd58d000 CR4:
00000000000406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process modprobe (pid: 2522, threadinfo
ffff8801009f0000, task
ffff8801009a93a0)
Stack:
ffff8801009f1e58 ffffffff812e8f6e ffff8801009f1e58 ffffffff812e7a80
ffff880000000010 ffff880103920400 ffff8801002fd0c0 ffff880103920468
0000000000000011 ffff880103920400 ffff8801009f1e48 ffffffff8115ab6a
Call Trace:
[<
ffffffff812e8f6e>] ? device_add+0x4f1/0x5e4
[<
ffffffff812e7a80>] ? dev_set_name+0x41/0x43
[<
ffffffff8115ab6a>] sysfs_create_group+0x13/0x15
[<
ffffffff810b857e>] blk_trace_init_sysfs+0x14/0x16
[<
ffffffff811ee58b>] blk_register_queue+0x4c/0xfd
[<
ffffffff811f3bdf>] add_disk+0xe4/0x29c
[<
ffffffffa007e2ab>] nbd_init+0x2ab/0x30d [nbd]
[<
ffffffffa007e000>] ? 0xffffffffa007dfff
[<
ffffffff8100020f>] do_one_initcall+0x7f/0x13e
[<
ffffffff8107ab0a>] sys_init_module+0xa1/0x1e3
[<
ffffffff814f3542>] system_call_fastpath+0x16/0x1b
Code: 41 57 41 56 41 55 41 54 53 48 83 ec 28 0f 1f 44 00 00 48 89 fb 41 89 f6 49 89 d4 48 85 ff 74 0b 85 f6 75 0b 48 83
7f 30 00 75 14 <0f> 0b eb fe b9 ea ff ff ff 48 83 7f 30 00 0f 84 09 01 00 00 49
RIP [<
ffffffff8115aa08>] internal_create_group+0x2f/0x166
RSP <
ffff8801009f1de8>
---[ end trace
753285ffbf72c57c ]---
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Cc: Paul Clements <Paul.Clements@steeleye.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Artem Bityutskiy [Tue, 31 May 2011 05:40:40 +0000 (08:40 +0300)]
UBIFS: fix memory leak on error path
commit
812eb258311f89bcd664a34a620f249d54a2cd83 upstream.
UBIFS leaks memory on error path in 'ubifs_jnl_update()' in case of write
failure because it forgets to free the 'struct ubifs_dent_node *dent' object.
Although the object is small, the alignment can make it large - e.g., 2KiB
if the min. I/O unit is 2KiB.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Artem Bityutskiy [Tue, 31 May 2011 04:03:21 +0000 (07:03 +0300)]
UBIFS: fix shrinker object count reports
commit
cf610bf4199770420629d3bc273494bd27ad6c1d upstream.
Sometimes VM asks the shrinker to return amount of objects it can shrink,
and we return the ubifs_clean_zn_cnt in that case. However, it is possible
that this counter is negative for a short period of time, due to the way
UBIFS TNC code updates it. And I can observe the following warnings sometimes:
shrink_slab: ubifs_shrinker+0x0/0x2b7 [ubifs] negative objects to delete nr=-
8541616642706119788
This patch makes sure UBIFS never returns negative count of objects.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Fri, 12 Feb 2010 17:13:55 +0000 (12:13 -0500)]
fix duplicate removal on error path in scsi_sysfs_add_sdev
commit
ee37e09d81a4acf328f68189af12f116401f8c0f upstream.
This patch (as1335) fixes a bug in scsi_sysfs_add_sdev(). Its callers
always remove the device if anything goes wrong, so it should never
remove the device.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Fri, 12 Feb 2010 17:13:39 +0000 (12:13 -0500)]
fix refcounting bug in scsi_get_host_dev
commit
d5469119f0098881ab7f991990ef4f81ef13a194 upstream.
This patch (as1334) fixes a bug in scsi_get_host_dev(). It
incorrectly calls get_device() on the new device's target.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Fri, 12 Feb 2010 17:13:31 +0000 (12:13 -0500)]
fix memory leak in scsi_report_lun_scan
commit
75f8ee8e01a6c96652f27da40d4bdac9e2e485f0 upstream.
This patch (as1333) fixes a bug in scsi_report_lun_scan(). If a
newly-allocated device can't be used, it should be deleted.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Patrick McHardy [Fri, 19 Feb 2010 17:18:37 +0000 (18:18 +0100)]
netfilter: nf_conntrack_reasm: properly handle packets fragmented into a single fragment
commit
9e2dcf72023d1447f09c47d77c99b0c49659e5ce upstream.
When an ICMPV6_PKT_TOOBIG message is received with a MTU below 1280,
all further packets include a fragment header.
Unlike regular defragmentation, conntrack also needs to "reassemble"
those fragments in order to obtain a packet without the fragment
header for connection tracking. Currently nf_conntrack_reasm checks
whether a fragment has either IP6_MF set or an offset != 0, which
makes it ignore those fragments.
Remove the invalid check and make reassembly handle fragment queues
containing only a single fragment.
Reported-and-tested-by: Ulrich Weber <uweber@astaro.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tian, Kevin [Thu, 12 May 2011 02:56:08 +0000 (10:56 +0800)]
xen mmu: fix a race window causing leave_mm BUG()
commit
7899891c7d161752f29abcc9bc0a9c6c3a3af26c upstream.
There's a race window in xen_drop_mm_ref, where remote cpu may exit
dirty bitmap between the check on this cpu and the point where remote
cpu handles drop request. So in drop_other_mm_ref we need check
whether TLB state is still lazy before calling into leave_mm. This
bug is rarely observed in earlier kernel, but exaggerated by the
commit
831d52bc153971b70e64eccfbed2b232394f22f8
("x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm")
which clears bitmap after changing the TLB state. the call trace is as below:
---------------------------------
kernel BUG at arch/x86/mm/tlb.c:61!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
CPU 1
Modules linked in: 8021q garp xen_netback xen_blkback blktap blkback_pagemap nbd bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc bonding ipv6 xenfs dm_multipath video output sbs sbshc parport_pc lp parport ses enclosure snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device serio_raw bnx2 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iTCO_wdt snd soundcore snd_page_alloc i2c_i801 iTCO_vendor_support i2c_core pcs pkr pata_acpi ata_generic ata_piix shpchp mptsas mptscsih mptbase [last unloaded: freq_table]
Pid: 25581, comm: khelper Not tainted 2.6.32.36fixxen #1 Tecal RH2285
RIP: e030:[<
ffffffff8103a3cb>] [<
ffffffff8103a3cb>] leave_mm+0x15/0x46
RSP: e02b:
ffff88002805be48 EFLAGS:
00010046
RAX:
0000000000000000 RBX:
0000000000000001 RCX:
ffff88015f8e2da0
RDX:
ffff88002805be78 RSI:
0000000000000000 RDI:
0000000000000001
RBP:
ffff88002805be48 R08:
ffff88009d662000 R09:
dead000000200200
R10:
dead000000100100 R11:
ffffffff814472b2 R12:
ffff88009bfc1880
R13:
ffff880028063020 R14:
00000000000004f6 R15:
0000000000000000
FS:
00007f62362d66e0(0000) GS:
ffff880028058000(0000) knlGS:
0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
0000003aabc11909 CR3:
000000009b8ca000 CR4:
0000000000002660
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
00000000000000 00
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process khelper (pid: 25581, threadinfo
ffff88007691e000, task
ffff88009b92db40)
Stack:
ffff88002805be68 ffffffff8100e4ae 0000000000000001 ffff88009d733b88
<0>
ffff88002805be98 ffffffff81087224 ffff88002805be78 ffff88002805be78
<0>
ffff88015f808360 00000000000004f6 ffff88002805bea8 ffffffff81010108
Call Trace:
<IRQ>
[<
ffffffff8100e4ae>] drop_other_mm_ref+0x2a/0x53
[<
ffffffff81087224>] generic_smp_call_function_single_interrupt+0xd8/0xfc
[<
ffffffff81010108>] xen_call_function_single_interrupt+0x13/0x28
[<
ffffffff810a936a>] handle_IRQ_event+0x66/0x120
[<
ffffffff810aac5b>] handle_percpu_irq+0x41/0x6e
[<
ffffffff8128c1c0>] __xen_evtchn_do_upcall+0x1ab/0x27d
[<
ffffffff8128dd11>] xen_evtchn_do_upcall+0x33/0x46
[<
ffffffff81013efe>] xen_do_hyper visor_callback+0x1e/0x30
<EOI>
[<
ffffffff814472b2>] ? _spin_unlock_irqrestore+0x15/0x17
[<
ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
[<
ffffffff81113f71>] ? flush_old_exec+0x3ac/0x500
[<
ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
[<
ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
[<
ffffffff8115115d>] ? load_elf_binary+0x398/0x17ef
[<
ffffffff81042fcf>] ? need_resched+0x23/0x2d
[<
ffffffff811f4648>] ? process_measurement+0xc0/0xd7
[<
ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
[<
ffffffff81113094>] ? search_binary_handler+0xc8/0x255
[<
ffffffff81114362>] ? do_execve+0x1c3/0x29e
[<
ffffffff8101155d>] ? sys_execve+0x43/0x5d
[<
ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
[<
ffffffff81013e28>] ? kernel_execve+0x68/0xd0
[<
ffffffff 8106fc45>] ? __call_usermodehelper+0x0/0x6f
[<
ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
[<
ffffffff8106fb64>] ? ____call_usermodehelper+0x113/0x11e
[<
ffffffff81013daa>] ? child_rip+0xa/0x20
[<
ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
[<
ffffffff81012f91>] ? int_ret_from_sys_call+0x7/0x1b
[<
ffffffff8101371d>] ? retint_restore_args+0x5/0x6
[<
ffffffff81013da0>] ? child_rip+0x0/0x20
Code: 41 5e 41 5f c9 c3 55 48 89 e5 0f 1f 44 00 00 e8 17 ff ff ff c9 c3 55 48 89 e5 0f 1f 44 00 00 65 8b 04 25 c8 55 01 00 ff c8 75 04 <0f> 0b eb fe 65 48 8b 34 25 c0 55 01 00 48 81 c6 b8 02 00 00 e8
RIP [<
ffffffff8103a3cb>] leave_mm+0x15/0x46
RSP <
ffff88002805be48>
---[ end trace
ce9cee6832a9c503 ]---
Tested-by: Maoxiaoyun<tinnycloud@hotmail.com>
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
[v1: Fleshed out the git description a bit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hemant Pedanekar [Tue, 5 Apr 2011 07:02:50 +0000 (12:32 +0530)]
PCI: Add quirk for setting valid class for TI816X Endpoint
commit
63c4408074cbcc070ac17fc10e524800eb9bd0b0 upstream.
TI816X (common name for DM816x/C6A816x/AM389x family) devices configured
to boot as PCIe Endpoint have class code = 0. This makes kernel PCI bus
code to skip allocating BARs to these devices resulting into following
type of error when trying to enable them:
"Device 0000:01:00.0 not available because of resource collisions"
The device cannot be operated because of the above issue.
This patch adds a ID specific (TI VENDOR ID and 816X DEVICE ID based)
'early' fixup quirk to replace class code with
PCI_CLASS_MULTIMEDIA_VIDEO as class.
Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Sat, 19 Mar 2011 00:21:23 +0000 (20:21 -0400)]
SUNRPC: Deal with the lack of a SYN_SENT sk->sk_state_change callback...
commit
fe19a96b10032035a35779f42ad59e35d6dd8ffd upstream.
The TCP connection state code depends on the state_change() callback
being called when the SYN_SENT state is set. However the networking layer
doesn't actually call us back in that case.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Namhyung Kim [Thu, 26 May 2011 19:06:50 +0000 (21:06 +0200)]
brd: handle on-demand devices correctly
commit
af46566885a373b0a526932484cd8fef8de7b598 upstream.
When finding or allocating a ram disk device, brd_probe() did not take
partition numbers into account so that it can result to a different
device. Consider following example (I set CONFIG_BLK_DEV_RAM_COUNT=4
for simplicity) :
$ sudo modprobe brd max_part=15
$ ls -l /dev/ram*
brw-rw---- 1 root disk 1, 0 2011-05-25 15:41 /dev/ram0
brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1
brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2
brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3
$ sudo mknod /dev/ram4 b 1 64
$ sudo dd if=/dev/zero of=/dev/ram4 bs=4k count=256
256+0 records in
256+0 records out
1048576 bytes (1.0 MB) copied, 0.
00215578 s, 486 MB/s
namhyung@leonhard:linux$ ls -l /dev/ram*
brw-rw---- 1 root disk 1, 0 2011-05-25 15:41 /dev/ram0
brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1
brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2
brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3
brw-r--r-- 1 root root 1, 64 2011-05-25 15:45 /dev/ram4
brw-rw---- 1 root disk 1, 1024 2011-05-25 15:44 /dev/ram64
After this patch, /dev/ram4 - instead of /dev/ram64 - was
accessed correctly.
In addition, 'range' passed to blk_register_region() should
include all range of dev_t that RAMDISK_MAJOR can address.
It does not need to be limited by partition numbers unless
'rd_nr' param was specified.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Namhyung Kim [Thu, 26 May 2011 19:06:50 +0000 (21:06 +0200)]
brd: limit 'max_part' module param to DISK_MAX_PARTS
commit
315980c8688c4b06713c1a5fe9d64cdf8ab57a72 upstream.
The 'max_part' parameter controls the number of maximum partition
a brd device can have. However if a user specifies very large
value it would exceed the limitation of device minor number and
can cause a kernel panic (or, at least, produce invalid device
nodes in some cases).
On my desktop system, following command kills the kernel. On qemu,
it triggers similar oops but the kernel was alive:
$ sudo modprobe brd max_part=100000
BUG: unable to handle kernel NULL pointer dereference at
0000000000000058
IP: [<
ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
PGD
7af1067 PUD
7b19067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file:
CPU 0
Modules linked in: brd(+)
Pid: 44, comm: insmod Tainted: G W 2.6.39-qemu+ #158 Bochs Bochs
RIP: 0010:[<
ffffffff81110a9a>] [<
ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
RSP: 0018:
ffff880007b15d78 EFLAGS:
00000286
RAX:
ffff880007b05478 RBX:
ffff880007a52760 RCX:
ffff880007b15dc8
RDX:
ffff880007a4f900 RSI:
ffff880007b15e48 RDI:
ffff880007a52760
RBP:
ffff880007b15da8 R08:
0000000000000002 R09:
0000000000000000
R10:
ffff880007b15e48 R11:
ffff880007b05478 R12:
0000000000000000
R13:
ffff880007b05478 R14:
0000000000400920 R15:
0000000000000063
FS:
0000000002160880(0063) GS:
ffff880007c00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000058 CR3:
0000000007b1c000 CR4:
00000000000006b0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
0000000000000000 DR7:
0000000000000000
Process insmod (pid: 44, threadinfo
ffff880007b14000, task
ffff880007acb980)
Stack:
ffff880007b15dc8 ffff880007b05478 ffff880007b15da8 00000000fffffffe
ffff880007a52760 ffff880007b05478 ffff880007b15de8 ffffffff81143c0a
0000000000400920 ffff880007a52760 ffff880007b05478 0000000000000000
Call Trace:
[<
ffffffff81143c0a>] kobject_add_internal+0xdf/0x1a0
[<
ffffffff81143da1>] kobject_add_varg+0x41/0x50
[<
ffffffff81143e6b>] kobject_add+0x64/0x66
[<
ffffffff8113bbe7>] blk_register_queue+0x5f/0xb8
[<
ffffffff81140f72>] add_disk+0xdf/0x289
[<
ffffffffa00040df>] brd_init+0xdf/0x1aa [brd]
[<
ffffffffa0004000>] ? 0xffffffffa0003fff
[<
ffffffffa0004000>] ? 0xffffffffa0003fff
[<
ffffffff8100020a>] do_one_initcall+0x7a/0x12e
[<
ffffffff8108516c>] sys_init_module+0x9c/0x1dc
[<
ffffffff812ff4bb>] system_call_fastpath+0x16/0x1b
Code: 89 e5 41 55 41 54 53 48 89 fb 48 83 ec 18 48 85 ff 75 04 0f 0b eb fe 48 8b 47 18 49 c7 c4 70 1e 4d 81 48 85 c0 74 04 4c 8b 60 30
8b 44 24 58 45 31 ed 0f b6 c4 85 c0 74 0d 48 8b 43 28 48 89
RIP [<
ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
RSP <
ffff880007b15d78>
CR2:
0000000000000058
---[ end trace
aebb1175ce1f6739 ]---
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Williams [Fri, 27 May 2011 04:51:54 +0000 (04:51 +0000)]
atm: expose ATM device index in sysfs
commit
e7a46b4d0839c2a3aa2e0ae0b145f293f6738498 upstream.
It's currently exposed only through /proc which, besides requiring
screen-scraping, doesn't allow userspace to distinguish between two
identical ATM adapters with different ATM indexes. The ATM device index
is required when using PPPoATM on a system with multiple ATM adapters.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Milan Broz [Sun, 29 May 2011 12:02:52 +0000 (13:02 +0100)]
dm table: reject devices without request fns
commit
f4808ca99a203f20b4475601748e44b25a65bdec upstream.
This patch adds a check that a block device has a request function
defined before it is used. Otherwise, misconfiguration can cause an oops.
Because we are allowing devices with zero size e.g. an offline multipath
device as in commit
2cd54d9bedb79a97f014e86c0da393416b264eb3
("dm: allow offline devices") there needs to be an additional check
to ensure devices are initialised. Some block devices, like a loop
device without a backing file, exist but have no request function.
Reproducer is trivial: dm-mirror on unbound loop device
(no backing file on loop devices)
dmsetup create x --table "0 8 mirror core 2 8 sync 2 /dev/loop0 0 /dev/loop1 0"
and mirror resync will immediatelly cause OOps.
BUG: unable to handle kernel NULL pointer dereference at (null)
? generic_make_request+0x2bd/0x590
? kmem_cache_alloc+0xad/0x190
submit_bio+0x53/0xe0
? bio_add_page+0x3b/0x50
dispatch_io+0x1ca/0x210 [dm_mod]
? read_callback+0x0/0xd0 [dm_mirror]
dm_io+0xbb/0x290 [dm_mod]
do_mirror+0x1e0/0x748 [dm_mirror]
Signed-off-by: Milan Broz <mbroz@redhat.com>
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tero Kristo [Thu, 24 Feb 2011 15:19:23 +0000 (17:19 +0200)]
cpuidle: menu: fixed wrapping timers at 4.294 seconds
commit
7467571f4480b273007517b26297c07154c73924 upstream.
Cpuidle menu governor is using u32 as a temporary datatype for storing
nanosecond values which wrap around at 4.294 seconds. This causes errors
in predicted sleep times resulting in higher than should be C state
selection and increased power consumption. This also breaks cpuidle
state residency statistics.
Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luca Tettamanti [Wed, 25 May 2011 18:43:31 +0000 (20:43 +0200)]
i8k: Avoid lahf in 64-bit code
commit
bc1f419c76a2d6450413ce4349f4e4a07be011d5 upstream.
i8k uses lahf to read the flag register in 64-bit code; early x86-64
CPUs, however, lack this instruction and we get an invalid opcode
exception at runtime.
Use pushf to load the flag register into the stack instead.
Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Reported-by: Jeff Rickman <jrickman@myamigos.us>
Tested-by: Jeff Rickman <jrickman@myamigos.us>
Tested-by: Harry G McGavran Jr <w5pny@arrl.net>
Cc: Massimo Dal Zotto <dz@debian.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Artem Bityutskiy [Fri, 6 May 2011 14:08:56 +0000 (17:08 +0300)]
UBIFS: fix a rare memory leak in ro to rw remounting path
commit
eaeee242c531cd4b0a4a46e8b5dd7ef504380c42 upstream.
When re-mounting from R/O mode to R/W mode and the LEB count in the superblock
is not up-to date, because for the underlying UBI volume became larger, we
re-write the superblock. We allocate RAM for these purposes, but never free it.
So this is a memory leak, although very rare one.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tyler Hicks [Tue, 17 May 2011 05:50:33 +0000 (00:50 -0500)]
eCryptfs: Allow 2 scatterlist entries for encrypted filenames
commit
8d08dab786ad5cc2aca2bf870de370144b78c85a upstream.
The buffers allocated while encrypting and decrypting long filenames can
sometimes straddle two pages. In this situation, virt_to_scatterlist()
will return -ENOMEM, causing the operation to fail and the user will get
scary error messages in their logs:
kernel: ecryptfs_write_tag_70_packet: Internal error whilst attempting
to convert filename memory to scatterlist; expected rc = 1; got rc =
[-12]. block_aligned_filename_size = [272]
kernel: ecryptfs_encrypt_filename: Error attempting to generate tag 70
packet; rc = [-12]
kernel: ecryptfs_encrypt_and_encode_filename: Error attempting to
encrypt filename; rc = [-12]
kernel: ecryptfs_lookup: Error attempting to encrypt and encode
filename; rc = [-12]
The solution is to allow up to 2 scatterlist entries to be used.
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Christian Lamparter [Fri, 13 May 2011 19:47:23 +0000 (21:47 +0200)]
p54usb: add zoom 4410 usbid
commit
9368a9a2378ab721f82f59430a135b4ce4ff5109 upstream.
Reported-by: Mark Davis <marked86@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Mon, 16 May 2011 16:15:19 +0000 (12:15 -0400)]
OHCI: fix regression caused by nVidia shutdown workaround
commit
2b7aaf503d56216b847c8265421d2a7d9b42df3e upstream.
This patch (as1463) fixes a regression caused by commit
3df7169e73fc1d71a39cffeacc969f6840cdf52b (OHCI: work around for nVidia
shutdown problem).
The original problem encountered by people using NVIDIA chipsets was
that USB devices were not turning off when the system shut down. For
example, the LED on an optical mouse would remain on, draining a
laptop's battery. The problem was caused by a bug in the chipset; an
OHCI controller in the Reset state would continue to drive a bus reset
signal even after system shutdown. The workaround was to put the
controllers into the Suspend state instead.
It turns out that later NVIDIA chipsets do not suffer from this bug.
Instead some have the opposite bug: If a system is shut down while an
OHCI controller is in the Suspend state, USB devices remain powered!
On other systems, shutting down with a Suspended controller causes the
system to reboot immediately. Thus, working around the original bug
on some machines exposes other bugs on other machines.
The best solution seems to be to limit the workaround to OHCI
controllers with a low-numbered PCI product ID. I don't know exactly
at what point NVIDIA changed their chipsets; the value used here is a
guess. So far it was worked out okay for all the people who have
tested it.
This fixes Bugzilla #35032.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
Tested-by: Yury Siamashka <yurand2@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Fri, 13 May 2011 20:10:01 +0000 (13:10 -0700)]
xhci: Fix full speed bInterval encoding.
commit
b513d44751bfb609a3c20463f764c8ce822d63e9 upstream.
Dmitry's patch
dfa49c4ad120a784ef1ff0717168aa79f55a483a USB: xhci - fix math in xhci_get_endpoint_interval()
introduced a bug. The USB 2.0 spec says that full speed isochronous endpoints'
bInterval must be decoded as an exponent to a power of two (e.g. interval =
2^(bInterval - 1)). Full speed interrupt endpoints, on the other hand, don't
use exponents, and the interval in frames is encoded straight into bInterval.
Dmitry's patch was supposed to fix up the full speed isochronous to parse
bInterval as an exponent, but instead it changed the *interrupt* endpoint
bInterval decoding. The isochronous endpoint encoding was the same.
This caused full speed devices with interrupt endpoints (including mice, hubs,
and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:
[ 100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
[ 100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev
ffff88011f0ea000
...
[ 100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
[ 100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev
ffff88011f0ea000
When the interrupt endpoint was added and a Configure Endpoint command was
issued to the host, the host controller would return a very odd error message
(0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
Probably the host controller was getting very confused with the bad encoding.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Felipe Balbi [Fri, 13 May 2011 13:53:48 +0000 (16:53 +0300)]
usb: gadget: rndis: don't test against req->length
commit
472b91274a6c6857877b5caddb875dcb5ecdfcb8 upstream.
composite.c always sets req->length to zero
and expects function driver's setup handlers
to return the amount of bytes to be used
on req->length. If we test against req->length
w_length will always be greater than req->length
thus making us always stall that particular
SEND_ENCAPSULATED_COMMAND request.
Tested against a Windows XP SP3.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>