Tomoya MORINAGA [Wed, 20 Jul 2011 11:17:49 +0000 (20:17 +0900)]
pch_uart: Set PCIe bus number using probe parameter
commit
6c4b47d243112e98811ce0da7bbb32cc3857dd1a upstream.
Currently, PCIe bus number is set as fixed value "2".
However, PCIe bus number is not always "2".
This patch sets bus number using probe() parameter.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonghwan Choi [Wed, 18 Apr 2012 21:23:04 +0000 (17:23 -0400)]
security: fix compile error in commoncap.c
commit
51b79bee627d526199b2f6a6bef8ee0c0739b6d1 upstream.
Add missing "personality.h"
security/commoncap.c: In function 'cap_bprm_set_creds':
security/commoncap.c:510: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function)
security/commoncap.c:510: error: (Each undeclared identifier is reported only once
security/commoncap.c:510: error: for each function it appears in.)
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lin Ming [Mon, 28 Nov 2011 01:46:02 +0000 (09:46 +0800)]
ACPICA: Fix to allow region arguments to reference other scopes
commit
8931d9ea78848b073bf299594f148b83abde4a5e upstream.
Allow referenced objects to be in a different scope.
http://www.acpica.org/bugzilla/show_bug.cgi?id=937
http://marc.info/?l=linux-acpi&m=
131636632718222&w=2
ACPI Error: [RAMB] Namespace lookup failure, AE_NOT_FOUND (
20110112/psargs-359)
ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (
20110112/nsinit-349)
Scope (_SB)
{
Name (RAMB, 0xDF5A1018)
OperationRegion (\RAMW, SystemMemory, RAMB, 0x00010000)
}
For above ASL code, we need to save scope node(\_SB) to lookup
the argument node(\_SB.RAMB).
Reported-by: Jim Green <student.northwestern@gmail.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomoya MORINAGA [Fri, 28 Oct 2011 00:37:34 +0000 (09:37 +0900)]
USB: pch_udc: Support new device LAPIS Semiconductor ML7831 IOH
commit
731ad81e2dd97e3f222361f7b3ff4b35639e46af upstream.
ML7831 is companion chip for Intel Atom E6xx series.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomoya MORINAGA [Thu, 12 Jan 2012 02:27:09 +0000 (11:27 +0900)]
usb: gadget: pch_udc: Reduce redundant interrupt
commit
833310402c54ad9b676b465fc53ad276b13d36be upstream.
ISSUE:
USB Suspend interrupts occur frequently.
CAUSE:
When it is called pch_udc_reconnect() in USB Suspend, it repeats reset and
Suspend.
SOLUTION:
pch_udc_reconnect() does not enable all interrupts. When an enumeration event
occurred the driver enables all interrupts.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomoya MORINAGA [Thu, 12 Jan 2012 02:27:08 +0000 (11:27 +0900)]
usb: gadget: pch_udc: Fix usb/gadget/pch_udc: Fix ether gadget connect/disconnect issue
commit
1c575d2d2e3ff2a7cb3c2e2165064199cfd8ad32 upstream.
ISSUE:
After a USB cable is connect/disconnected, the system rarely freezes.
CAUSE:
Since the USB device controller cannot know to disconnect the USB cable, when
it is used without detecting VBUS by GPIO, the UDC driver does not notify to
USB Gadget.
Since USB Gadget cannot know to disconnect, a false setting occurred when the
USB cable is connected/disconnect repeatedly.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomoya MORINAGA [Thu, 12 Jan 2012 02:27:07 +0000 (11:27 +0900)]
usb: gadget: pch_udc: Fix USB suspend issue
commit
84566abba058b2aae8d603dfa90b5a3778a6714f upstream.
ISSUE:
After USB Suspend, a system rarely freezes.
CAUSE:
When USB Suspend occurred, the driver is not notifying
a gadget of the event.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomoya MORINAGA [Thu, 12 Jan 2012 02:27:06 +0000 (11:27 +0900)]
usb: gadget: pch_udc: Fix wrong return value
commit
c802672cd36cd063bfd54d54c8c34825ab5b2357 upstream.
ISSUE:
If the return value of pch_udc_pcd_init() is False, the return value of
this function is unsettled.
Since pch_udc_pcd_init() always returns 0, there is not actually the issue.
CAUSE:
If pch_udc_pcd_init() is True, the variable, retval, is not set for an
appropriate value.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomoya MORINAGA [Thu, 12 Jan 2012 02:27:05 +0000 (11:27 +0900)]
usb: gadget: pch_udc: Fix disconnect issue
commit
c50a3bff0edb0acd49d8033a12ea4668e09a31ad upstream.
ISSUE:
When the driver notifies a gadget of a disconnect event, a system
rarely freezes.
CAUSE:
When the driver calls dev->driver->disconnect(), it is not calling
spin_unlock().
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomoya MORINAGA [Fri, 11 Nov 2011 01:12:17 +0000 (10:12 +0900)]
pch_phub: Improve ADE(Address Decode Enable) control
commit
9914a0de7a27ef2cb5d9aacfe50ae97ebb532f28 upstream.
Currently, external ROM access is enabled/disabled in probe()/remove().
So, when a buggy software access unanticipated memory area,
in case of enabling this ADE bit,
external ROM memory area can be broken.
This patch enables the ADE bit only accessing external ROM area.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: Masayuki Ohtak <masa-korg@dsn.okisemi.com>
Cc: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Denis Turischev <denis@compulab.co.il>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tomoya MORINAGA [Thu, 21 Jul 2011 08:07:08 +0000 (17:07 +0900)]
pch_phub: Care FUNCSEL register in PM
commit
dd7d7fea29c18b818e94f252a76f495490d399c3 upstream.
Only ML7213/ML7223(Bus-n) has this register.
Currently,this driver doesn't care register "FUNCSEL" in suspend/resume.
This patch saves/restores FUNCSEL register only when the device is ML7213 or
ML7223(Bus-n).
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tomoya MORINAGA [Fri, 17 Jun 2011 01:13:26 +0000 (10:13 +0900)]
pch_phub: Fix register miss-setting issue
commit
20ae6d0b307963416db0e8433602e5d5c95e942b upstream.
Register "interrupt delay value" is for GbE which is connected to Bus-m of PCIe.
However currently, the value is set for Bus-n.
As a result, the value is not set correctly.
This patch moves setting the value processing of Bus-n to Bus-m.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Johan Hovold [Thu, 15 Mar 2012 13:48:41 +0000 (14:48 +0100)]
Bluetooth: hci_core: fix NULL-pointer dereference at unregister
commit
94324962066231a938564bebad0f941cd2d06bb2 upstream.
Make sure hci_dev_open returns immediately if hci_dev_unregister has
been called.
This fixes a race between hci_dev_open and hci_dev_unregister which can
lead to a NULL-pointer dereference.
Bug is 100% reproducible using hciattach and a disconnected serial port:
0. # hciattach -n /dev/ttyO1 any noflow
1. hci_dev_open called from hci_power_on grabs req lock
2. hci_init_req executes but device fails to initialise (times out
eventually)
3. hci_dev_open is called from hci_sock_ioctl and sleeps on req lock
4. hci_uart_tty_close calls hci_dev_unregister and sleeps on req lock in
hci_dev_do_close
5. hci_dev_open (1) releases req lock
6. hci_dev_do_close grabs req lock and returns as device is not up
7. hci_dev_unregister sleeps in destroy_workqueue
8. hci_dev_open (3) grabs req lock, calls hci_init_req and eventually sleeps
9. hci_dev_unregister finishes, while hci_dev_open is still running...
[ 79.627136] INFO: trying to register non-static key.
[ 79.632354] the code is fine but needs lockdep annotation.
[ 79.638122] turning off the locking correctness validator.
[ 79.643920] [<
c00188bc>] (unwind_backtrace+0x0/0xf8) from [<
c00729c4>] (__lock_acquire+0x1590/0x1ab0)
[ 79.653594] [<
c00729c4>] (__lock_acquire+0x1590/0x1ab0) from [<
c00733f8>] (lock_acquire+0x9c/0x128)
[ 79.663085] [<
c00733f8>] (lock_acquire+0x9c/0x128) from [<
c0040a88>] (run_timer_softirq+0x150/0x3ac)
[ 79.672668] [<
c0040a88>] (run_timer_softirq+0x150/0x3ac) from [<
c003a3b8>] (__do_softirq+0xd4/0x22c)
[ 79.682281] [<
c003a3b8>] (__do_softirq+0xd4/0x22c) from [<
c003a924>] (irq_exit+0x8c/0x94)
[ 79.690856] [<
c003a924>] (irq_exit+0x8c/0x94) from [<
c0013a50>] (handle_IRQ+0x34/0x84)
[ 79.699157] [<
c0013a50>] (handle_IRQ+0x34/0x84) from [<
c0008530>] (omap3_intc_handle_irq+0x48/0x4c)
[ 79.708648] [<
c0008530>] (omap3_intc_handle_irq+0x48/0x4c) from [<
c037499c>] (__irq_usr+0x3c/0x60)
[ 79.718048] Exception stack(0xcf281fb0 to 0xcf281ff8)
[ 79.723358] 1fa0:
0001e6a0 be8dab00 0001e698 00036698
[ 79.731933] 1fc0:
0002df98 0002df38 0000001f 00000000 b6f234d0 00000000 00000004 00000000
[ 79.740509] 1fe0:
0001e6f8 be8d6aa0 be8dac50 0000aab8 80000010 ffffffff
[ 79.747497] Unable to handle kernel NULL pointer dereference at virtual address
00000000
[ 79.756011] pgd =
cf3b4000
[ 79.758850] [
00000000] *pgd=
8f0c7831, *pte=
00000000, *ppte=
00000000
[ 79.765502] Internal error: Oops:
80000007 [#1]
[ 79.770294] Modules linked in:
[ 79.773529] CPU: 0 Tainted: G W (
3.3.0-rc6-00002-gb5d5c87 #421)
[ 79.781066] PC is at 0x0
[ 79.783721] LR is at run_timer_softirq+0x16c/0x3ac
[ 79.788787] pc : [<
00000000>] lr : [<
c0040aa4>] psr:
60000113
[ 79.788787] sp :
cf281ee0 ip :
00000000 fp :
cf280000
[ 79.800903] r10:
00000004 r9 :
00000100 r8 :
b6f234d0
[ 79.806427] r7 :
c0519c28 r6 :
cf093488 r5 :
c0561a00 r4 :
00000000
[ 79.813323] r3 :
00000000 r2 :
c054eee0 r1 :
00000001 r0 :
00000000
[ 79.820190] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 79.827728] Control:
10c5387d Table:
8f3b4019 DAC:
00000015
[ 79.833801] Process gpsd (pid: 1265, stack limit = 0xcf2802e8)
[ 79.839965] Stack: (0xcf281ee0 to 0xcf282000)
[ 79.844573] 1ee0:
00000002 00000000 c0040a24 00000000 00000002 cf281f08 00200200 00000000
[ 79.853210] 1f00:
00000000 cf281f18 cf281f08 00000000 00000000 00000000 cf281f18 cf281f18
[ 79.861816] 1f20:
00000000 00000001 c056184c 00000000 00000001 b6f234d0 c0561848 00000004
[ 79.870452] 1f40:
cf280000 c003a3b8 c051e79c 00000001 00000000 00000100 3fa9e7b8 0000000a
[ 79.879089] 1f60:
00000025 cf280000 00000025 00000000 00000000 b6f234d0 00000000 00000004
[ 79.887756] 1f80:
00000000 c003a924 c053ad38 c0013a50 fa200000 cf281fb0 ffffffff c0008530
[ 79.896362] 1fa0:
0001e6a0 0000aab8 80000010 c037499c 0001e6a0 be8dab00 0001e698 00036698
[ 79.904998] 1fc0:
0002df98 0002df38 0000001f 00000000 b6f234d0 00000000 00000004 00000000
[ 79.913665] 1fe0:
0001e6f8 be8d6aa0 be8dac50 0000aab8 80000010 ffffffff 00fbf700 04ffff00
[ 79.922302] [<
c0040aa4>] (run_timer_softirq+0x16c/0x3ac) from [<
c003a3b8>] (__do_softirq+0xd4/0x22c)
[ 79.931945] [<
c003a3b8>] (__do_softirq+0xd4/0x22c) from [<
c003a924>] (irq_exit+0x8c/0x94)
[ 79.940582] [<
c003a924>] (irq_exit+0x8c/0x94) from [<
c0013a50>] (handle_IRQ+0x34/0x84)
[ 79.948913] [<
c0013a50>] (handle_IRQ+0x34/0x84) from [<
c0008530>] (omap3_intc_handle_irq+0x48/0x4c)
[ 79.958404] [<
c0008530>] (omap3_intc_handle_irq+0x48/0x4c) from [<
c037499c>] (__irq_usr+0x3c/0x60)
[ 79.967773] Exception stack(0xcf281fb0 to 0xcf281ff8)
[ 79.973083] 1fa0:
0001e6a0 be8dab00 0001e698 00036698
[ 79.981658] 1fc0:
0002df98 0002df38 0000001f 00000000 b6f234d0 00000000 00000004 00000000
[ 79.990234] 1fe0:
0001e6f8 be8d6aa0 be8dac50 0000aab8 80000010 ffffffff
[ 79.997161] Code: bad PC value
[ 80.000396] ---[ end trace
6f6739840475f9ee ]---
[ 80.005279] Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sarah Sharp [Fri, 16 Mar 2012 20:19:35 +0000 (13:19 -0700)]
xhci: Fix register save/restore order.
commit
c7713e736526d8c9f6f87716fb90562a8ffaff2c upstream.
The xHCI 1.0 spec errata released on June 13, 2011, changes the ordering
that the xHCI registers are saved and restored in. It moves the
interrupt pending (IMAN) and interrupt control (IMOD) registers to be
saved and restored last. I believe that's because the host controller
may attempt to fetch the event ring table when interrupts are
re-enabled. Therefore we need to restore the event ring registers
before we re-enable interrupts.
This should be backported to kernels as old as 2.6.37, that contain the
commit
5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI: PCI power
management implementation"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rajkumar Manoharan [Thu, 15 Mar 2012 00:38:04 +0000 (06:08 +0530)]
ath9k: fix max noise floor threshold
commit
2ee0a07028d2cde6e131b73f029dae2b93c50f3a upstream.
Currently the maximum noise floor limit is set as too high (-60dB). The
assumption of having a higher threshold limit is that it would help
de-sensitize the receiver (reduce phy errors) from continuous
interference. But when we have a bursty interference where there are
collisions and then free air time and if the receiver is desensitized too
much, it will miss the normal packets too. Lets make use of chips
specific min, nom and max limits always. This patch helps to improve the
connection stability in congested networks.
Cc: Paul Stewart <pstew@google.com>
Tested-by: Gary Morain <gmorain@google.com>
Signed-off-by: Madhan Jaganathan <madhanj@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.0/3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Paris [Tue, 17 Apr 2012 20:26:54 +0000 (16:26 -0400)]
fcaps: clear the same personality flags as suid when fcaps are used
commit
d52fc5dde171f030170a6cb78034d166b13c9445 upstream.
If a process increases permissions using fcaps all of the dangerous
personality flags which are cleared for suid apps should also be cleared.
Thus programs given priviledge with fcaps will continue to have address space
randomization enabled even if the parent tried to disable it to make it
easier to attack.
Signed-off-by: Eric Paris <eparis@redhat.com>
Reviewed-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Wed, 21 Mar 2012 19:15:18 +0000 (20:15 +0100)]
serial: PL011: move interrupt clearing
commit
c3d8b76f61586714cdc5f219ba45592a54caaa55 upstream.
Commit
360f748b204275229f8398cb2f9f53955db1503b
"serial: PL011: clear pending interrupts"
attempts to clear interrupts by writing to a
yet-unassigned memory address. This fixes the issue.
The breaking patch is marked for stable so should be
carried along with the other patch.
Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Nicolas Pitre <nico@fluxnic.net>
Reported-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Tue, 13 Mar 2012 12:27:23 +0000 (13:27 +0100)]
serial: PL011: clear pending interrupts
commit
9b96fbacda34079dea0638ee1e92c56286f6114a upstream.
Chanho Min reported that when the boot loader transfers
control to the kernel, there may be pending interrupts
causing the UART to lock up in an eternal loop trying to
pick tokens from the FIFO (since the RX interrupt flag
indicates there are tokens) while in practice there are
no tokens - in fact there is only a pending IRQ flag.
This patch address the issue with a combination of two
patches suggested by Russell King that clears and mask
all interrupts at probe() and clears any pending error
and RX interrupts at port startup time.
We suspect the spurious interrupts are a side-effect of
switching the UART from FIFO to non-FIFO mode.
Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Reported-by: Chanho Min <chanho0207@gmail.com>
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Jong-Sung Kim <neidhard.kim@lge.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Elric Fu [Thu, 29 Mar 2012 07:47:50 +0000 (15:47 +0800)]
xHCI: add XHCI_RESET_ON_RESUME quirk for VIA xHCI host
commit
457a4f61f9bfc3ae76e5b49f30f25d86bb696f67 upstream.
The suspend operation of VIA xHCI host have some issues and
hibernate operation works fine, so The XHCI_RESET_ON_RESUME
quirk is added for it.
This patch should base on "xHCI: Don't write zeroed pointer
to xHC registers" that is released by Sarah. Otherwise, the
host system error will ocurr in the hibernate operation
process.
This should be backported to stable kernels as old as 2.6.37,
that contain the commit
c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9
"xhci: Add reset on resume quirk for asrock p67 host".
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex He [Fri, 30 Mar 2012 02:21:38 +0000 (10:21 +0800)]
xHCI: Correct the #define XHCI_LEGACY_DISABLE_SMI
commit
95018a53f7653e791bba1f54c8d75d9cb700d1bd upstream.
Re-define XHCI_LEGACY_DISABLE_SMI and used it in right way. All SMI enable
bits will be cleared to zero and flag bits 29:31 are also cleared to zero.
Other bits should be presvered as Table 146.
This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sarah Sharp [Fri, 16 Mar 2012 20:27:39 +0000 (13:27 -0700)]
xhci: Restore event ring dequeue pointer on resume.
commit
fb3d85bc7193f23c9a564502df95564c49a32c91 upstream.
The xhci_save_registers() function saved the event ring dequeue pointer
in the s3 register structure, but xhci_restore_registers() never
restored it. No other code in the xHCI successful resume path would
ever restore it either. Fix that.
This should be backported to kernels as old as 2.6.37, that contain the
commit
5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI: PCI power
management implementation".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sarah Sharp [Fri, 16 Mar 2012 20:09:39 +0000 (13:09 -0700)]
xhci: Don't write zeroed pointers to xHC registers.
commit
159e1fcc9a60fc7daba23ee8fcdb99799de3fe84 upstream.
When xhci_mem_cleanup() is called, we can't be sure if the xHC is
actually halted. We can ask the xHC to halt by writing to the RUN bit
in the command register, but that might timeout due to a HW hang.
If the host controller is still running, we should not write zeroed
values to the event ring dequeue pointers or base tables, the DCBAA
pointers, or the command ring pointers. Eric Fu reports his VIA VL800
host accesses the event ring pointers after a failed register restore on
resume from suspend. The hypothesis is that the host never actually
halted before the register write to change the event ring pointer to
zero.
Remove all writes of zeroed values to pointer registers in
xhci_mem_cleanup(). Instead, make all callers of the function reset the
host controller first, which will reset those registers to zero.
xhci_mem_init() is the only caller that doesn't first halt and reset the
host controller before calling xhci_mem_cleanup().
This should be backported to kernels as old as 2.6.32.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felipe Balbi [Thu, 15 Mar 2012 14:37:08 +0000 (16:37 +0200)]
xhci: don't re-enable IE constantly
commit
4e833c0b87a30798e67f06120cecebef6ee9644c upstream.
While we're at that, define IMAN bitfield to aid readability.
The interrupt enable bit should be set once on driver init, and we
shouldn't need to continually re-enable it. Commit
c21599a3 introduced
a read of the irq_pending register, and that allows us to preserve the
state of the IE bit. Before that commit, we were blindly writing 0x3 to
the register.
This patch should be backported to kernels as old as 2.6.36, or ones
that contain the commit
c21599a36165dbc78b380846b254017a548b9de5 "USB:
xhci: Reduce reads and writes of interrupter registers".
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Thu, 22 Mar 2012 15:00:21 +0000 (11:00 -0400)]
USB: don't clear urb->dev in scatter-gather library
commit
bcf398537630bf20b4dbe59ba855b69f404c93cf upstream.
This patch (as1517b) fixes an error in the USB scatter-gather library.
The library code uses urb->dev to determine whether or nor an URB is
currently active; the completion handler sets urb->dev to NULL.
However the core unlinking routines need to use urb->dev. Since
unlinking always racing with completion, the completion handler must
not clear urb->dev -- it can lead to invalid memory accesses when a
transfer has to be cancelled.
This patch fixes the problem by getting rid of the lines that clear
urb->dev after urb has been submitted. As a result we may end up
trying to unlink an URB that failed in submission or that has already
completed, so an extra check is added after each unlink to avoid
printing an error message when this happens. The checks are updated
in both sg_complete() and sg_cancel(), and the second is updated to
match the first (currently it prints out unnecessary warning messages
if a device is unplugged while a transfer is in progress).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Illia Zaitsev <I.Zaitsev@adbglobal.com>
CC: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anton Samokhvalov [Wed, 4 Apr 2012 18:26:01 +0000 (22:26 +0400)]
USB: sierra: add support for Sierra Wireless MC7710
commit
c5d703dcc776cb542b41665f2b7e2ba054efb4a7 upstream.
Just add new device id. 3G works fine, LTE not tested.
Signed-off-by: Anton Samokhvalov <pg83@yandex.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Santiago Garcia Mantinan [Mon, 19 Mar 2012 17:17:00 +0000 (18:17 +0100)]
USB: option: re-add NOVATELWIRELESS_PRODUCT_HSPA_HIGHSPEED to option_id array
commit
9ac2feb22b5b821d81463bef92698ef7682a3145 upstream.
Re-add NOVATELWIRELESS_PRODUCT_HSPA_HIGHSPEED to option_id array
Signed-off-by: Santiago Garcia Mantinan <manty@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 23 Mar 2012 14:23:18 +0000 (15:23 +0100)]
USB: pl2303: fix DTR/RTS being raised on baud rate change
commit
ce5c9851855bab190c9a142761d54ba583ab094c upstream.
DTR/RTS should only be raised when changing baudrate from B0 and not on
any baud rate change (> B0).
Reported-by: Søren Holm <sgh@sgh.dk>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 20 Mar 2012 15:59:33 +0000 (16:59 +0100)]
USB: serial: fix race between probe and open
commit
a65a6f14dc24a90bde3f5d0073ba2364476200bf upstream.
Fix race between probe and open by making sure that the disconnected
flag is not cleared until all ports have been registered.
A call to tty_open while probe is running may get a reference to the
serial structure in serial_install before its ports have been
registered. This may lead to usb_serial_core calling driver open before
port is fully initialised.
With ftdi_sio this result in the following NULL-pointer dereference as
the private data has not been initialised at open:
[ 199.698286] IP: [<
f811a089>] ftdi_open+0x59/0xe0 [ftdi_sio]
[ 199.698297] *pde =
00000000
[ 199.698303] Oops: 0000 [#1] PREEMPT SMP
[ 199.698313] Modules linked in: ftdi_sio usbserial
[ 199.698323]
[ 199.698327] Pid: 1146, comm: ftdi_open Not tainted 3.2.11 #70 Dell Inc. Vostro 1520/0T816J
[ 199.698339] EIP: 0060:[<
f811a089>] EFLAGS:
00010286 CPU: 0
[ 199.698344] EIP is at ftdi_open+0x59/0xe0 [ftdi_sio]
[ 199.698348] EAX:
0000003e EBX:
f5067000 ECX:
00000000 EDX:
80000600
[ 199.698352] ESI:
f48d8800 EDI:
00000001 EBP:
f515dd54 ESP:
f515dcfc
[ 199.698356] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 199.698361] Process ftdi_open (pid: 1146, ti=
f515c000 task=
f481e040 task.ti=
f515c000)
[ 199.698364] Stack:
[ 199.698368]
f811a9fe f811a9e0 f811b3ef 00000000 00000000 00001388 00000000 f4a86800
[ 199.698387]
00000002 00000000 f806e68e 00000000 f532765c f481e040 00000246 22222222
[ 199.698479]
22222222 22222222 22222222 f5067004 f5327600 f5327638 f515dd74 f806e6ab
[ 199.698496] Call Trace:
[ 199.698504] [<
f806e68e>] ? serial_activate+0x2e/0x70 [usbserial]
[ 199.698511] [<
f806e6ab>] serial_activate+0x4b/0x70 [usbserial]
[ 199.698521] [<
c126380c>] tty_port_open+0x7c/0xd0
[ 199.698527] [<
f806e660>] ? serial_set_termios+0xa0/0xa0 [usbserial]
[ 199.698534] [<
f806e76f>] serial_open+0x2f/0x70 [usbserial]
[ 199.698540] [<
c125d07c>] tty_open+0x20c/0x510
[ 199.698546] [<
c10e9eb7>] chrdev_open+0xe7/0x230
[ 199.698553] [<
c10e48f2>] __dentry_open+0x1f2/0x390
[ 199.698559] [<
c144bfec>] ? _raw_spin_unlock+0x2c/0x50
[ 199.698565] [<
c10e4b76>] nameidata_to_filp+0x66/0x80
[ 199.698570] [<
c10e9dd0>] ? cdev_put+0x20/0x20
[ 199.698576] [<
c10f3e08>] do_last+0x198/0x730
[ 199.698581] [<
c10f4440>] path_openat+0xa0/0x350
[ 199.698587] [<
c10f47d5>] do_filp_open+0x35/0x80
[ 199.698593] [<
c144bfec>] ? _raw_spin_unlock+0x2c/0x50
[ 199.698599] [<
c10ff110>] ? alloc_fd+0xc0/0x100
[ 199.698605] [<
c10f0b72>] ? getname_flags+0x72/0x120
[ 199.698611] [<
c10e4450>] do_sys_open+0xf0/0x1c0
[ 199.698617] [<
c11fcc08>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 199.698623] [<
c10e458e>] sys_open+0x2e/0x40
[ 199.698628] [<
c144c990>] sysenter_do_call+0x12/0x36
[ 199.698632] Code: 85 89 00 00 00 8b 16 8b 4d c0 c1 e2 08 c7 44 24 14 88 13 00 00 81 ca 00 00 00 80 c7 44 24 10 00 00 00 00 c7 44 24 0c 00 00 00 00 <0f> b7 41 78 31 c9 89 44 24 08 c7 44 24 04 00 00 00 00 c7 04 24
[ 199.698884] EIP: [<
f811a089>] ftdi_open+0x59/0xe0 [ftdi_sio] SS:ESP 0068:
f515dcfc
[ 199.698893] CR2:
0000000000000078
[ 199.698925] ---[ end trace
77c43ec023940cff ]---
Reported-and-tested-by: Ken Huang <csuhgw@gmail.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neal Cardwell [Tue, 27 Mar 2012 19:09:37 +0000 (15:09 -0400)]
nohz: Fix stale jiffies update in tick_nohz_restart()
commit
6f103929f8979d2638e58d7f7fda0beefcb8ee7e upstream.
Fix tick_nohz_restart() to not use a stale ktime_t "now" value when
calling tick_do_update_jiffies64(now).
If we reach this point in the loop it means that we crossed a tick
boundary since we grabbed the "now" timestamp, so at this point "now"
refers to a time in the old jiffy, so using the old value for "now" is
incorrect, and is likely to give us a stale jiffies value.
In particular, the first time through the loop the
tick_do_update_jiffies64(now) call is always a no-op, since the
caller, tick_nohz_restart_sched_tick(), will have already called
tick_do_update_jiffies64(now) with that "now" value.
Note that tick_nohz_stop_sched_tick() already uses the correct
approach: when we notice we cross a jiffy boundary, grab a new
timestamp with ktime_get(), and *then* update jiffies.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Cc: Ben Segall <bsegall@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Link: http://lkml.kernel.org/r/1332875377-23014-1-git-send-email-ncardwell@google.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wang YanQing [Sun, 1 Apr 2012 00:54:02 +0000 (08:54 +0800)]
video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
commit
b78f29ca0516266431688c5eb42d39ce42ec039a upstream.
This patch fix the oops below that catched in my machine
[ 81.560602] uvesafb: NVIDIA Corporation, GT216 Board -
0696a290, Chip Rev , OEM: NVIDIA, VBE v3.0
[ 81.609384] uvesafb: protected mode interface info at c000:d350
[ 81.609388] uvesafb: pmi: set display start =
c00cd3b3, set palette =
c00cd40e
[ 81.609390] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
[ 81.614558] uvesafb: VBIOS/hardware doesn't support DDC transfers
[ 81.614562] uvesafb: no monitor limits have been set, default refresh rate will be used
[ 81.614994] uvesafb: scrolling: ypan using protected mode interface, yres_virtual=4915
[ 81.744147] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[ 81.744153] BUG: unable to handle kernel paging request at
c00cd3b3
[ 81.744159] IP: [<
c00cd3b3>] 0xc00cd3b2
[ 81.744167] *pdpt =
00000000016d6001 *pde =
0000000001c7b067 *pte =
80000000000cd163
[ 81.744171] Oops: 0011 [#1] SMP
[ 81.744174] Modules linked in: uvesafb(+) cfbcopyarea cfbimgblt cfbfillrect
[ 81.744178]
[ 81.744181] Pid: 3497, comm: modprobe Not tainted 3.3.0-rc4NX+ #71 Acer Aspire 4741 /Aspire 4741
[ 81.744185] EIP: 0060:[<
c00cd3b3>] EFLAGS:
00010246 CPU: 0
[ 81.744187] EIP is at 0xc00cd3b3
[ 81.744189] EAX:
00004f07 EBX:
00000000 ECX:
00000000 EDX:
00000000
[ 81.744191] ESI:
f763f000 EDI:
f763f6e8 EBP:
f57f3a0c ESP:
f57f3a00
[ 81.744192] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 81.744195] Process modprobe (pid: 3497, ti=
f57f2000 task=
f748c600 task.ti=
f57f2000)
[ 81.744196] Stack:
[ 81.744197]
f82512c5 f759341c 00000000 f57f3a30 c124a9bc 00000001 00000001 000001e0
[ 81.744202]
f8251280 f763f000 f7593400 00000000 f57f3a40 c12598dd f5c0c000 00000000
[ 81.744206]
f57f3b10 c1255efe c125a21a 00000006 f763f09c 00000000 c1c6cb60 f7593400
[ 81.744210] Call Trace:
[ 81.744215] [<
f82512c5>] ? uvesafb_pan_display+0x45/0x60 [uvesafb]
[ 81.744222] [<
c124a9bc>] fb_pan_display+0x10c/0x160
[ 81.744226] [<
f8251280>] ? uvesafb_vbe_find_mode+0x180/0x180 [uvesafb]
[ 81.744230] [<
c12598dd>] bit_update_start+0x1d/0x50
[ 81.744232] [<
c1255efe>] fbcon_switch+0x39e/0x550
[ 81.744235] [<
c125a21a>] ? bit_cursor+0x4ea/0x560
[ 81.744240] [<
c129b6cb>] redraw_screen+0x12b/0x220
[ 81.744245] [<
c128843b>] ? tty_do_resize+0x3b/0xc0
[ 81.744247] [<
c129ef42>] vc_do_resize+0x3d2/0x3e0
[ 81.744250] [<
c129efb4>] vc_resize+0x14/0x20
[ 81.744253] [<
c12586bd>] fbcon_init+0x29d/0x500
[ 81.744255] [<
c12984c4>] ? set_inverse_trans_unicode+0xe4/0x110
[ 81.744258] [<
c129b378>] visual_init+0xb8/0x150
[ 81.744261] [<
c129c16c>] bind_con_driver+0x16c/0x360
[ 81.744264] [<
c129b47e>] ? register_con_driver+0x6e/0x190
[ 81.744267] [<
c129c3a1>] take_over_console+0x41/0x50
[ 81.744269] [<
c1257b7a>] fbcon_takeover+0x6a/0xd0
[ 81.744272] [<
c12594b8>] fbcon_event_notify+0x758/0x790
[ 81.744277] [<
c10929e2>] notifier_call_chain+0x42/0xb0
[ 81.744280] [<
c1092d30>] __blocking_notifier_call_chain+0x60/0x90
[ 81.744283] [<
c1092d7a>] blocking_notifier_call_chain+0x1a/0x20
[ 81.744285] [<
c124a5a1>] fb_notifier_call_chain+0x11/0x20
[ 81.744288] [<
c124b759>] register_framebuffer+0x1d9/0x2b0
[ 81.744293] [<
c1061c73>] ? ioremap_wc+0x33/0x40
[ 81.744298] [<
f82537c6>] uvesafb_probe+0xaba/0xc40 [uvesafb]
[ 81.744302] [<
c12bb81f>] platform_drv_probe+0xf/0x20
[ 81.744306] [<
c12ba558>] driver_probe_device+0x68/0x170
[ 81.744309] [<
c12ba731>] __device_attach+0x41/0x50
[ 81.744313] [<
c12b9088>] bus_for_each_drv+0x48/0x70
[ 81.744316] [<
c12ba7f3>] device_attach+0x83/0xa0
[ 81.744319] [<
c12ba6f0>] ? __driver_attach+0x90/0x90
[ 81.744321] [<
c12b991f>] bus_probe_device+0x6f/0x90
[ 81.744324] [<
c12b8a45>] device_add+0x5e5/0x680
[ 81.744329] [<
c122a1a3>] ? kvasprintf+0x43/0x60
[ 81.744332] [<
c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
[ 81.744335] [<
c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
[ 81.744339] [<
c12bbe9f>] platform_device_add+0xff/0x1b0
[ 81.744343] [<
f8252906>] uvesafb_init+0x50/0x9b [uvesafb]
[ 81.744346] [<
c100111f>] do_one_initcall+0x2f/0x170
[ 81.744350] [<
f82528b6>] ? uvesafb_is_valid_mode+0x66/0x66 [uvesafb]
[ 81.744355] [<
c10c6994>] sys_init_module+0xf4/0x1410
[ 81.744359] [<
c1157fc0>] ? vfsmount_lock_local_unlock_cpu+0x30/0x30
[ 81.744363] [<
c144cb10>] sysenter_do_call+0x12/0x36
[ 81.744365] Code: f5 00 00 00 32 f6 66 8b da 66 d1 e3 66 ba d4 03 8a e3 b0 1c 66 ef b0 1e 66 ef 8a e7 b0 1d 66 ef b0 1f 66 ef e8 fa 00 00 00 61 c3 <60> e8 c8 00 00 00 66 8b f3 66 8b da 66 ba d4 03 b0 0c 8a e5 66
[ 81.744388] EIP: [<
c00cd3b3>] 0xc00cd3b3 SS:ESP 0068:
f57f3a00
[ 81.744391] CR2:
00000000c00cd3b3
[ 81.744393] ---[ end trace
18b2c87c925b54d6 ]---
Signed-off-by: Wang YanQing <udknight@gmail.com>
Cc: Michal Januszewski <spock@gentoo.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Miller [Tue, 27 Mar 2012 07:14:18 +0000 (03:14 -0400)]
perf hists: Catch and handle out-of-date hist entry maps.
commit
63fa471dd49e9c9ce029d910d1024330d9b1b145 upstream.
When a process exec()'s, all the maps are retired, but we keep the hist
entries around which hold references to those outdated maps.
If the same library gets mapped in for which we have hist entries, a new
map will be created. But when we take a perf entry hit within that map,
we'll find the existing hist entry with the older map.
This causes symbol translations to be done incorrectly. For example,
the perf entry processing will lookup the correct uptodate map entry and
use that to calculate the symbol and DSO relative address. But later
when we update the histogram we'll translate the address using the
outdated map file instead leading to conditions such as out-of-range
offsets in symbol__inc_addr_samples().
Therefore, update the map of the hist_entry dynamically at lookup/
creation time.
Signed-off-by: David S. Miller <davem@davemloft.net>
Link: http://lkml.kernel.org/r/20120327.031418.1220315351537060808.davem@davemloft.net
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen M. Cameron [Thu, 22 Mar 2012 20:40:09 +0000 (21:40 +0100)]
cciss: Fix scsi tape io with more than 255 scatter gather elements
commit
bc67f63650fad6b3478d9ddfd5406d45a95987c9 upstream.
The total number of scatter gather elements in the CISS command
used by the scsi tape code was being cast to a u8, which can hold
at most 255 scatter gather elements. It should have been cast to
a u16. Without this patch the command gets rejected by the controller
since the total scatter gather count did not add up to the right
value resulting in an i/o error.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen M. Cameron [Thu, 22 Mar 2012 20:40:08 +0000 (21:40 +0100)]
cciss: Initialize scsi host max_sectors for tape drive support
commit
395d287526bb60411ff37b19ad9dd38b58ba8732 upstream.
The default is too small (1024 blocks), use h->cciss_max_sectors (8192 blocks)
Without this change, if you try to set the block size of a tape drive above
512*1024, via "mt -f /dev/st0 setblk nnn" where nnn is greater than 524288,
it won't work right.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Fri, 13 Apr 2012 18:56:22 +0000 (11:56 -0700)]
sparc64: Fix bootup crash on sun4v.
commit
9e0daff30fd7ecf698e5d20b0fa7f851e427cca5 upstream.
The DS driver registers as a subsys_initcall() but this can be too
early, in particular this risks registering before we've had a chance
to allocate and setup module_kset in kernel/params.c which is
performed also as a subsyts_initcall().
Register DS using device_initcall() insteal.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul E. McKenney [Fri, 13 Apr 2012 03:35:13 +0000 (03:35 +0000)]
sparc64: Eliminate obsolete __handle_softirq() function
commit
3d3eeb2ef26112a200785e5fca58ec58dd33bf1e upstream.
The invocation of softirq is now handled by irq_exit(), so there is no
need for sparc64 to invoke it on the trap-return path. In fact, doing so
is a bug because if the trap occurred in the idle loop, this invocation
can result in lockdep-RCU failures. The problem is that RCU ignores idle
CPUs, and the sparc64 trap-return path to the softirq handlers fails to
tell RCU that the CPU must be considered non-idle while those handlers
are executing. This means that RCU is ignoring any RCU read-side critical
sections in those handlers, which in turn means that RCU-protected data
can be yanked out from under those read-side critical sections.
The shiny new lockdep-RCU ability to detect RCU read-side critical sections
that RCU is ignoring located this problem.
The fix is straightforward: Make sparc64 stop manually invoking the
softirq handlers.
Reported-by: Meelis Roos <mroos@linux.ee>
Suggested-by: David Miller <davem@davemloft.net>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yuriy Kozlov [Thu, 29 Mar 2012 07:55:27 +0000 (09:55 +0200)]
tty: serial: altera_uart: Check for NULL platform_data in probe.
commit
acede70d6561f2d042d9dbb153d9a3469479c0ed upstream.
Follow altera_jtag_uart. This fixes a crash if there is a mistake in the DTS.
Signed-off-by: Yuriy Kozlov <ykozlov@ptcusa.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marek Belisko [Thu, 12 Apr 2012 19:48:03 +0000 (21:48 +0200)]
staging: iio: hmc5843: Fix crash in probe function.
commit
62d2feb9803f18c4e3c8a1a2c7e30a54df8a1d72 upstream.
Fix crash after issuing:
echo hmc5843 0x1e > /sys/class/i2c-dev/i2c-2/device/new_device
[ 37.180999] device: '2-001e': device_add
[ 37.188293] bus: 'i2c': add device 2-001e
[ 37.194549] PM: Adding info for i2c:2-001e
[ 37.200958] bus: 'i2c': driver_probe_device: matched device 2-001e with driver hmc5843
[ 37.210815] bus: 'i2c': really_probe: probing driver hmc5843 with device 2-001e
[ 37.224884] HMC5843 initialized
[ 37.228759] ------------[ cut here ]------------
[ 37.233612] kernel BUG at mm/slab.c:505!
[ 37.237701] Internal error: Oops - BUG: 0 [#1] PREEMPT
[ 37.243103] Modules linked in:
[ 37.246337] CPU: 0 Not tainted (3.3.1-gta04+ #28)
[ 37.251647] PC is at kfree+0x84/0x144
[ 37.255493] LR is at kfree+0x20/0x144
[ 37.259338] pc : [<
c00b408c>] lr : [<
c00b4028>] psr:
40000093
[ 37.259368] sp :
de249cd8 ip :
0000000c fp :
00000090
[ 37.271362] r10:
0000000a r9 :
de229eac r8 :
c0236274
[ 37.276855] r7 :
c09d6490 r6 :
a0000013 r5 :
de229c00 r4 :
de229c10
[ 37.283691] r3 :
c0f00218 r2 :
00000400 r1 :
c0eea000 r0 :
c00b4028
[ 37.290527] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
[ 37.298095] Control:
10c5387d Table:
9e1d0019 DAC:
00000015
[ 37.304107] Process sh (pid: 91, stack limit = 0xde2482f0)
[ 37.309844] Stack: (0xde249cd8 to 0xde24a000)
[ 37.314422] 9cc0:
de229c10 de229c00
[ 37.322998] 9ce0:
de229c10 ffffffea 00000005 c0236274 de140a80 c00b4798 dec00080 de140a80
[ 37.331573] 9d00:
c032f37c dec00080 000080d0 00000001 de229c00 de229c10 c048d578 00000005
[ 37.340148] 9d20:
de229eac 0000000a 00000090 c032fa40 00000001 00000000 00000001 de229c10
[ 37.348724] 9d40:
de229eac 00000029 c075b558 00000001 00000003 00000004 de229c10 c048d594
[ 37.357299] 9d60:
00000000 60000013 00000018 205b0007 37332020 3432322e 5d343838 c0060020
[ 37.365905] 9d80:
de251600 00000001 00000000 de251600 00000001 c0065a84 de229c00 de229c48
[ 37.374481] 9da0:
00000006 0048d62c de229c38 de229c00 de229c00 de1f6c00 de1f6c20 00000001
[ 37.383056] 9dc0:
00000000 c048d62c 00000000 de229c00 de229c00 de1f6c00 de1f6c20 00000001
[ 37.391632] 9de0:
00000000 c048d62c 00000000 c0330164 00000000 de1f6c20 c048d62c de1f6c00
[ 37.400207] 9e00:
c0330078 de1f6c04 c078d714 de189b58 00000000 c02ccfd8 de1f6c20 c0795f40
[ 37.408782] 9e20:
c0238330 00000000 00000000 c02381a8 de1b9fc0 de1f6c20 de1f6c20 de249e48
[ 37.417358] 9e40:
c0238330 c0236bb0 decdbed8 de7d0f14 de1f6c20 de1f6c20 de1f6c54 de1f6c20
[ 37.425933] 9e60:
00000000 c0238030 de1f6c20 c078d7bc de1f6c20 c02377ec de1f6c20 de1f6c28
[ 37.434509] 9e80:
dee64cb0 c0236138 c047c554 de189b58 00000000 c004b45c de1f6c20 de1f6cd8
[ 37.443084] 9ea0:
c0edfa6c de1f6c00 dee64c68 de1f6c04 de1f6c20 dee64cb8 c047c554 de189b58
[ 37.451690] 9ec0:
00000000 c02cd634 dee64c68 de249ef4 de23b008 dee64cb0 0000000d de23b000
[ 37.460266] 9ee0:
de23b007 c02cd78c 00000002 00000000 00000000 35636d68 00333438 00000000
[ 37.468841] 9f00:
00000000 00000000 001e0000 00000000 00000000 00000000 00000000 0a10cec0
[ 37.477416] 9f20:
00000002 de249f80 0000000d dee62990 de189b40 c0234d88 0000000d c010c354
[ 37.485992] 9f40:
0000000d de210f28 000acc88 de249f80 0000000d de248000 00000000 c00b7bf8
[ 37.494567] 9f60:
de210f28 000acc88 de210f28 000acc88 00000000 00000000 0000000d c00b7ed8
[ 37.503143] 9f80:
00000000 00000000 0000000d 00000000 0007fa28 0000000d 000acc88 00000004
[ 37.511718] 9fa0:
c000e544 c000e380 0007fa28 0000000d 00000001 000acc88 0000000d 00000000
[ 37.520294] 9fc0:
0007fa28 0000000d 000acc88 00000004 00000001 00000020 00000002 00000000
[ 37.528869] 9fe0:
00000000 beab8624 0000ea05 b6eaebac 600d0010 00000001 00000000 00000000
[ 37.537475] [<
c00b408c>] (kfree+0x84/0x144) from [<
c0236274>] (device_add+0x530/0x57c)
[ 37.545806] [<
c0236274>] (device_add+0x530/0x57c) from [<
c032fa40>] (iio_device_register+0x8c8/0x990)
[ 37.555480] [<
c032fa40>] (iio_device_register+0x8c8/0x990) from [<
c0330164>] (hmc5843_probe+0xec/0x114)
[ 37.565338] [<
c0330164>] (hmc5843_probe+0xec/0x114) from [<
c02ccfd8>] (i2c_device_probe+0xc4/0xf8)
[ 37.574737] [<
c02ccfd8>] (i2c_device_probe+0xc4/0xf8) from [<
c02381a8>] (driver_probe_device+0x118/0x218)
[ 37.584777] [<
c02381a8>] (driver_probe_device+0x118/0x218) from [<
c0236bb0>] (bus_for_each_drv+0x4c/0x84)
[ 37.594818] [<
c0236bb0>] (bus_for_each_drv+0x4c/0x84) from [<
c0238030>] (device_attach+0x78/0xa4)
[ 37.604125] [<
c0238030>] (device_attach+0x78/0xa4) from [<
c02377ec>] (bus_probe_device+0x28/0x9c)
[ 37.613433] [<
c02377ec>] (bus_probe_device+0x28/0x9c) from [<
c0236138>] (device_add+0x3f4/0x57c)
[ 37.622650] [<
c0236138>] (device_add+0x3f4/0x57c) from [<
c02cd634>] (i2c_new_device+0xf8/0x19c)
[ 37.631805] [<
c02cd634>] (i2c_new_device+0xf8/0x19c) from [<
c02cd78c>] (i2c_sysfs_new_device+0xb4/0x130)
[ 37.641754] [<
c02cd78c>] (i2c_sysfs_new_device+0xb4/0x130) from [<
c0234d88>] (dev_attr_store+0x18/0x24)
[ 37.651611] [<
c0234d88>] (dev_attr_store+0x18/0x24) from [<
c010c354>] (sysfs_write_file+0x10c/0x140)
[ 37.661193] [<
c010c354>] (sysfs_write_file+0x10c/0x140) from [<
c00b7bf8>] (vfs_write+0xb0/0x178)
[ 37.670410] [<
c00b7bf8>] (vfs_write+0xb0/0x178) from [<
c00b7ed8>] (sys_write+0x3c/0x68)
[ 37.678833] [<
c00b7ed8>] (sys_write+0x3c/0x68) from [<
c000e380>] (ret_fast_syscall+0x0/0x3c)
[ 37.687683] Code:
1593301c e5932000 e3120080 1a000000 (
e7f001f2)
[ 37.700775] ---[ end trace
aaf805debdb69390 ]---
Client data was assigned to iio_dev structure in probe but in
hmc5843_init_client function casted to private driver data structure which
is wrong. Possibly calling mutex_init(&data->lock); corrupt data
which the lead to above crash.
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Metcalf [Thu, 12 Apr 2012 19:49:15 +0000 (12:49 -0700)]
hugetlb: fix race condition in hugetlb_fault()
commit
66aebce747eaf9bc456bf1f1b217d8db843031d0 upstream.
The race is as follows:
Suppose a multi-threaded task forks a new process (on cpu A), thus
bumping up the ref count on all the pages. While the fork is occurring
(and thus we have marked all the PTEs as read-only), another thread in
the original process (on cpu B) tries to write to a huge page, taking an
access violation from the write-protect and calling hugetlb_cow(). Now,
suppose the fork() fails. It will undo the COW and decrement the ref
count on the pages, so the ref count on the huge page drops back to 1.
Meanwhile hugetlb_cow() also decrements the ref count by one on the
original page, since the original address space doesn't need it any
more, having copied a new page to replace the original page. This
leaves the ref count at zero, and when we call unlock_page(), we panic.
fork on CPU A fault on CPU B
============= ==============
...
down_write(&parent->mmap_sem);
down_write_nested(&child->mmap_sem);
...
while duplicating vmas
if error
break;
...
up_write(&child->mmap_sem);
up_write(&parent->mmap_sem); ...
down_read(&parent->mmap_sem);
...
lock_page(page);
handle COW
page_mapcount(old_page) == 2
alloc and prepare new_page
...
handle error
page_remove_rmap(page);
put_page(page);
...
fold new_page into pte
page_remove_rmap(page);
put_page(page);
...
oops ==> unlock_page(page);
up_read(&parent->mmap_sem);
The solution is to take an extra reference to the page while we are
holding the lock on it.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Cc: Hillf Danton <dhillf@gmail.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Hugh Dickins <hughd@google.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@linuxfoundation.org>
Linus Walleij [Thu, 12 Apr 2012 19:49:16 +0000 (12:49 -0700)]
drivers/rtc/rtc-pl031.c: enable clock on all ST variants
commit
2f3972168353d355854d6381f1f360ce83b723e5 upstream.
The ST variants of the PL031 all require bit 26 in the control register
to be set before they work properly. Discovered this when testing on
the Nomadik board where it would suprisingly just stand still.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Mian Yousaf Kaukab <mian.yousaf.kaukab@stericsson.com>
Cc: Alessandro Rubini <rubini@unipv.it>
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@linuxfoundation.org>
Luck, Tony [Mon, 16 Apr 2012 23:28:01 +0000 (16:28 -0700)]
ia64: fix futex_atomic_cmpxchg_inatomic()
commit
c76f39bddb84f93f70a5520d9253ec0317bec216 upstream.
Michel Lespinasse cleaned up the futex calling conventions in commit
37a9d912b24f ("futex: Sanitize cmpxchg_futex_value_locked API").
But the ia64 implementation was subtly broken. Gcc does not know that
register "r8" will be updated by the fault handler if the cmpxchg
instruction takes an exception. So it feels safe in letting the
initialization of r8 slide to after the cmpxchg. Result: we always
return 0 whether the user address faulted or not.
Fix by moving the initialization of r8 into the __asm__ code so gcc
won't move it.
Reported-by: <emeric.maschino@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42757
Tested-by: <emeric.maschino@gmail.com>
Acked-by: Michel Lespinasse <walken@google.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 15 Mar 2012 13:48:40 +0000 (14:48 +0100)]
Bluetooth: hci_ldisc: fix NULL-pointer dereference on tty_close
commit
33b69bf80a3704d45341928e4ff68b6ebd470686 upstream.
Do not close protocol driver until device has been unregistered.
This fixes a race between tty_close and hci_dev_open which can result in
a NULL-pointer dereference.
The line discipline closes the protocol driver while we may still have
hci_dev_open sleeping on the req_lock mutex resulting in a NULL-pointer
dereference when lock is acquired and hci_init_req called.
Bug is 100% reproducible using hciattach and a disconnected serial port:
0. # hciattach -n ttyO1 any noflow
1. hci_dev_open called from hci_power_on grabs req lock
2. hci_init_req executes but device fails to initialise (times out
eventually)
3. hci_dev_open is called from hci_sock_ioctl and sleeps on req lock
4. hci_uart_tty_close detaches protocol driver and cancels init req
5. hci_dev_open (1) releases req lock
6. hci_dev_open (3) grabs req lock, calls hci_init_req, which triggers oops
when request is prepared in hci_uart_send_frame
[ 137.201263] Unable to handle kernel NULL pointer dereference at virtual address
00000028
[ 137.209838] pgd =
c0004000
[ 137.212677] [
00000028] *pgd=
00000000
[ 137.216430] Internal error: Oops: 17 [#1]
[ 137.220642] Modules linked in:
[ 137.223846] CPU: 0 Tainted: G W (3.3.0-rc6-dirty #406)
[ 137.230529] PC is at __lock_acquire+0x5c/0x1ab0
[ 137.235290] LR is at lock_acquire+0x9c/0x128
[ 137.239776] pc : [<
c0071490>] lr : [<
c00733f8>] psr:
20000093
[ 137.239776] sp :
cf869dd8 ip :
c0529554 fp :
c051c730
[ 137.251800] r10:
00000000 r9 :
cf8673c0 r8 :
00000080
[ 137.257293] r7 :
00000028 r6 :
00000002 r5 :
00000000 r4 :
c053fd70
[ 137.264129] r3 :
00000000 r2 :
00000000 r1 :
00000000 r0 :
00000001
[ 137.270965] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 137.278717] Control:
10c5387d Table:
8f0f4019 DAC:
00000015
[ 137.284729] Process kworker/u:1 (pid: 7, stack limit = 0xcf8682e8)
[ 137.291229] Stack: (0xcf869dd8 to 0xcf86a000)
[ 137.295776] 9dc0:
c0529554 00000000
[ 137.304351] 9de0:
cf8673c0 cf868000 d03ea1ef cf868000 000001ef 00000470 00000000 00000002
[ 137.312927] 9e00:
cf8673c0 00000001 c051c730 c00716ec 0000000c 00000440 c0529554 00000001
[ 137.321533] 9e20:
c051c730 cf868000 d03ea1f3 00000000 c053b978 00000000 00000028 cf868000
[ 137.330078] 9e40:
00000000 00000000 00000002 00000000 00000000 c00733f8 00000002 00000080
[ 137.338684] 9e60:
00000000 c02a1d50 00000000 00000001 60000013 c0969a1c 60000093 c053b96c
[ 137.347259] 9e80:
00000002 00000018 20000013 c02a1d50 cf0ac000 00000000 00000002 cf868000
[ 137.355834] 9ea0:
00000089 c0374130 00000002 00000000 c02a1d50 cf0ac000 0000000c cf0fc540
[ 137.364410] 9ec0:
00000018 c02a1d50 cf0fc540 00000000 cf0fc540 c0282238 c028220c cf178d80
[ 137.372985] 9ee0:
127525d8 c02821cc 9a1fa451 c032727c 9a1fa451 127525d8 cf0fc540 cf0ac4ec
[ 137.381561] 9f00:
cf0ac000 cf0fc540 cf0ac584 c03285f4 c0328580 cf0ac4ec cf85c740 c05510cc
[ 137.390136] 9f20:
ce825400 c004c914 00000002 00000000 c004c884 ce8254f5 cf869f48 00000000
[ 137.398712] 9f40:
c0328580 ce825415 c0a7f914 c061af64 00000000 c048cf3c cf8673c0 cf85c740
[ 137.407287] 9f60:
c05510cc c051a66c c05510ec c05510c4 cf85c750 cf868000 00000089 c004d6ac
[ 137.415863] 9f80:
00000000 c0073d14 00000001 cf853ed8 cf85c740 c004d558 00000013 00000000
[ 137.424438] 9fa0:
00000000 00000000 00000000 c00516b0 00000000 00000000 cf85c740 00000000
[ 137.433013] 9fc0:
00000001 dead4ead ffffffff ffffffff c0551674 00000000 00000000 c0450aa4
[ 137.441589] 9fe0:
cf869fe0 cf869fe0 cf853ed8 c005162c c0013b30 c0013b30 00ffff00 00ffff00
[ 137.450164] [<
c0071490>] (__lock_acquire+0x5c/0x1ab0) from [<
c00733f8>] (lock_acquire+0x9c/0x128)
[ 137.459503] [<
c00733f8>] (lock_acquire+0x9c/0x128) from [<
c0374130>] (_raw_spin_lock_irqsave+0x44/0x58)
[ 137.469360] [<
c0374130>] (_raw_spin_lock_irqsave+0x44/0x58) from [<
c02a1d50>] (skb_queue_tail+0x18/0x48)
[ 137.479339] [<
c02a1d50>] (skb_queue_tail+0x18/0x48) from [<
c0282238>] (h4_enqueue+0x2c/0x34)
[ 137.488189] [<
c0282238>] (h4_enqueue+0x2c/0x34) from [<
c02821cc>] (hci_uart_send_frame+0x34/0x68)
[ 137.497497] [<
c02821cc>] (hci_uart_send_frame+0x34/0x68) from [<
c032727c>] (hci_send_frame+0x50/0x88)
[ 137.507171] [<
c032727c>] (hci_send_frame+0x50/0x88) from [<
c03285f4>] (hci_cmd_work+0x74/0xd4)
[ 137.516204] [<
c03285f4>] (hci_cmd_work+0x74/0xd4) from [<
c004c914>] (process_one_work+0x1a0/0x4ec)
[ 137.525604] [<
c004c914>] (process_one_work+0x1a0/0x4ec) from [<
c004d6ac>] (worker_thread+0x154/0x344)
[ 137.535278] [<
c004d6ac>] (worker_thread+0x154/0x344) from [<
c00516b0>] (kthread+0x84/0x90)
[ 137.543975] [<
c00516b0>] (kthread+0x84/0x90) from [<
c0013b30>] (kernel_thread_exit+0x0/0x8)
[ 137.552734] Code:
e59f4e5c e5941000 e3510000 0a000031 (
e5971000)
[ 137.559234] ---[ end trace
1b75b31a2719ed1e ]---
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 11 Apr 2012 09:24:35 +0000 (11:24 +0200)]
Bluetooth: uart-ldisc: Fix memory leak
This is a partial, self-contained, minimal backport of commit
797fe796c4335b35d95d5326824513befdb5d1e9 upstream which fixes the memory
leak:
Bluetooth: uart-ldisc: Fix memory leak and remove destruct cb
We currently leak the hci_uart object if HCI_UART_PROTO_SET is never set
because the hci-destruct callback will then never be called. This fix
removes the hci-destruct callback and frees the driver internal private
hci_uart object directly on tty-close. We call hci_unregister_dev() here
so the hci-core will never call our callbacks again (except destruct).
Therefore, we can safely free the driver internal data right away and
set the destruct callback to NULL.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Austin [Thu, 12 Apr 2012 16:45:25 +0000 (17:45 +0100)]
ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE
commit
078c04545ba56da21567728a909a496df5ff730d upstream.
Currently when ThumbEE is not enabled (!CONFIG_ARM_THUMBEE) the ThumbEE
register states are not saved/restored at context switch. The default state
of the ThumbEE Ctrl register (TEECR) allows userspace accesses to the
ThumbEE Base Handler register (TEEHBR). This can cause unexpected behaviour
when people use ThumbEE on !CONFIG_ARM_THUMBEE kernels, as well as allowing
covert communication - eg between userspace tasks running inside chroot
jails.
This patch sets up TEECR in order to prevent user-space access to TEEHBR
when !CONFIG_ARM_THUMBEE. In this case, tasks are sent SIGILL if they try to
access TEEHBR.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Mon, 26 Mar 2012 15:48:20 +0000 (10:48 -0500)]
rtlwifi: Add missing DMA buffer unmapping for PCI drivers
commit
673f7786e205c87b5d978c62827b9a66d097bebb upstream.
In https://bugzilla.kernel.org/show_bug.cgi?id=42976, a system with driver
rtl8192se used as an AP suffers from "Out of SW-IOMMU space" errors. These
are caused by the DMA buffers used for beacons never being unmapped.
This bug was also reported at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/961618
Reported-and-Tested-by: Da Xue <da@lessconfused.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 10 Apr 2012 16:14:27 +0000 (12:14 -0400)]
drm/radeon: only add the mm i2c bus if the hw_i2c module param is set
commit
46783150a6552f9513f08e62cfcc07125d6e502b upstream.
It seems it can corrupt the monitor EDID in certain cases on certain
boards when running sensors detect. It's rarely used anyway outside
of AIW boards.
http://lists.lm-sensors.org/pipermail/lm-sensors/2012-April/035847.html
http://lists.freedesktop.org/archives/xorg/2011-January/052239.html
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Mon, 9 Apr 2012 12:59:46 +0000 (13:59 +0100)]
drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g
commit
27c1cbd06a7620b354cbb363834f3bb8df4f410d upstream.
The 845g shares the errata with i830 whereby executing a command
within 2 cachelines of the end of the ringbuffer may cause a GPU hang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 13 Apr 2012 15:26:29 +0000 (08:26 -0700)]
Linux 3.0.28
Peter Hurley [Mon, 2 Apr 2012 11:44:56 +0000 (13:44 +0200)]
Bluetooth: Fix l2cap conn failures for ssp devices
commit
18daf1644e634bae951a6e3d4d19d89170209762 upstream
Commit
330605423c fixed l2cap conn establishment for non-ssp remote
devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security
is tested (which was always returning failure on any subsequent
security checks).
However, this broke l2cap conn establishment for ssp remote devices
when an ACL link was already established at SDP-level security. This
fix ensures that encryption must be pending whenever authentication
is also pending.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Tetsuo Handa [Wed, 11 Apr 2012 01:54:43 +0000 (20:54 -0500)]
TOMOYO: Fix mount flags checking order.
commit
df91e49477a9be15921cb2854e1d12a3bdb5e425 upstream.
Userspace can pass in arbitrary combinations of MS_* flags to mount().
If both MS_BIND and one of MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE are
passed, device name which should be checked for MS_BIND was not checked because
MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE had higher priority than MS_BIND.
If both one of MS_BIND/MS_MOVE and MS_REMOUNT are passed, device name which
should not be checked for MS_REMOUNT was checked because MS_BIND/MS_MOVE had
higher priority than MS_REMOUNT.
Fix these bugs by changing priority to MS_REMOUNT -> MS_BIND ->
MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE -> MS_MOVE as with do_mount() does.
Also, unconditionally return -EINVAL if more than one of
MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE is passed so that TOMOYO will not
generate inaccurate audit logs, for commit
7a2e8a8f "VFS: Sanity check mount
flags passed to change_mnt_propagation()" clarified that these flags must be
exclusively passed.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joerg Roedel [Wed, 11 Apr 2012 16:45:52 +0000 (18:45 +0200)]
iommu/amd: Make sure IOMMU interrupts are re-enabled on resume
commit
9ddd592a191b32f2ee6c4b6ed2bd52665c3a49f5 upstream.
Unfortunatly the interrupts for the event log and the
peripheral page-faults are only enabled at boot but not
re-enabled at resume. Fix that.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
[bwh: Backport to 3.0:
- Drop change to PPR log which was added in 3.3
- Source is under arch/x86/kernel]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Mon, 9 Apr 2012 19:03:50 +0000 (21:03 +0200)]
cred: copy_process() should clear child->replacement_session_keyring
commit
79549c6dfda0603dba9a70a53467ce62d9335c33 upstream.
keyctl_session_to_parent(task) sets ->replacement_session_keyring,
it should be processed and cleared by key_replace_session_keyring().
However, this task can fork before it notices TIF_NOTIFY_RESUME and
the new child gets the bogus ->replacement_session_keyring copied by
dup_task_struct(). This is obviously wrong and, if nothing else, this
leads to put_cred(already_freed_cred).
change copy_creds() to clear this member. If copy_process() fails
before this point the wrong ->replacement_session_keyring doesn't
matter, exit_creds() won't be called.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kuninori Morimoto [Thu, 5 Apr 2012 06:28:01 +0000 (23:28 -0700)]
ASoC: ak4642: fixup: mute needs +1 step
commit
1f99e44cf059d2ed43c5a0724fa738b83800f725 upstream.
ak4642 out_tlv is +12.0dB to -115.0 dB, and it supports mute.
But current settings didn't care +1 step for mute.
This patch adds it
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guan Xin [Mon, 26 Mar 2012 04:11:46 +0000 (04:11 +0000)]
USB: Add Motorola Rokr E6 Id to the USBNet driver "zaurus"
commit
a2daf263107ba3eb6db33931881731fa51c95045 upstream.
Added Vendor/Device Id of Motorola Rokr E6 (22b8:6027) so it can be
recognized by the "zaurus" USBNet driver.
Applies to Linux 3.2.13 and 2.6.39.4.
Signed-off-by: Guan Xin <guanx.bac@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nishanth Menon [Thu, 23 Feb 2012 02:03:45 +0000 (20:03 -0600)]
mfd: Clear twl6030 IRQ status register only once
commit
3f8349e6e98ba0455437724589072523865eae5e upstream.
TWL6030 family of PMIC use a shadow interrupt status register
while kernel processes the current interrupt event.
However, any write(0 or 1) to register INT_STS_A, INT_STS_B or
INT_STS_C clears all 3 interrupt status registers.
Since clear of the interrupt is done on 32k clk, depending on I2C
bus speed, we could in-adverently clear the status of a interrupt
status pending on shadow register in the current implementation.
This is due to the fact that multi-byte i2c write operation into
three seperate status register could result in multiple load
and clear of status and result in lost interrupts.
Instead, doing a single byte write to INT_STS_A register with 0x0
will clear all three interrupt status registers without the related
risk.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Salman Qazi [Sat, 10 Mar 2012 00:41:01 +0000 (16:41 -0800)]
sched/x86: Fix overflow in cyc2ns_offset
commit
9993bc635d01a6ee7f6b833b4ee65ce7c06350b1 upstream.
When a machine boots up, the TSC generally gets reset. However,
when kexec is used to boot into a kernel, the TSC value would be
carried over from the previous kernel. The computation of
cycns_offset in set_cyc2ns_scale is prone to an overflow, if the
machine has been up more than 208 days prior to the kexec. The
overflow happens when we multiply *scale, even though there is
enough room to store the final answer.
We fix this issue by decomposing tsc_now into the quotient and
remainder of division by CYC2NS_SCALE_FACTOR and then performing
the multiplication separately on the two components.
Refactor code to share the calculation with the previous
fix in __cycles_2_ns().
Signed-off-by: Salman Qazi <sqazi@google.com>
Acked-by: John Stultz <john.stultz@linaro.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Turner <pjt@google.com>
Cc: john stultz <johnstul@us.ibm.com>
Link: http://lkml.kernel.org/r/20120310004027.19291.88460.stgit@dungbeetle.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Mike Galbraith <efault@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lee, Chun-Yi [Fri, 23 Mar 2012 04:36:44 +0000 (12:36 +0800)]
acer-wmi: No wifi rfkill on Sony machines
commit
5719b81988f3c24ff694dc3a37e35b35630a3966 upstream.
The wireless rfkill should charged by sony-laptop but not acer-wmi.
So, add Sony's SNY5001 acpi device to blacklist in acer-wmi.
Tested on Sony Vaio
Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Mattia Dongili <malattia@linux.it>
Cc: Dimitris N <ddarlac@gmail.com>
Tested-by: Dimitris N <ddarlac@gmail.com>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Tue, 10 Apr 2012 23:04:49 +0000 (16:04 -0700)]
Revert "x86/ioapic: Add register level checks to detect bogus io-apic entries"
This reverts commit
c2ec63edaf48c90c3495eeb0b75bb05102fbf71a
[
73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream]
It causes problems, so needs to be reverted from 3.2-stable for now.
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jon Dufresne <jon@jondufresne.org>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: <yinghai@kernel.org>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Teck Choon Giam <giamteckchoon@gmail.com>
Cc: Ben Guthro <ben@guthro.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Nieder [Tue, 28 Feb 2012 21:31:35 +0000 (15:31 -0600)]
x86/PCI: do not tie MSI MS-7253 use_crs quirk to BIOS version
commit
a97f4f5e524bcd09a85ef0b8821a14d35e69335f upstream.
Carlos was getting
WARNING: at drivers/pci/pci.c:118 pci_ioremap_bar+0x24/0x52()
when probing his sound card, and sound did not work. After adding
pci=use_crs to the kernel command line, no more trouble.
Ok, we can add a quirk. dmidecode output reveals that this is an MSI
MS-7253, for which we already have a quirk, but the short-sighted
author tied the quirk to a single BIOS version, making it not kick in
on Carlos's machine with BIOS V1.2. If a later BIOS update makes it
no longer necessary to look at the _CRS info it will still be
harmless, so let's stop trying to guess which versions have and don't
have accurate _CRS tables.
Addresses https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5533
Also see <https://bugzilla.kernel.org/show_bug.cgi?id=42619>.
Reported-by: Carlos Luna <caralu74@gmail.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Nieder [Tue, 28 Feb 2012 18:51:10 +0000 (11:51 -0700)]
x86/PCI: use host bridge _CRS info on MSI MS-7253
commit
8411371709610c826bf65684f886bfdfb5780ca1 upstream.
In the spirit of commit
29cf7a30f8a0 ("x86/PCI: use host bridge _CRS
info on ASUS M2V-MX SE"), this DMI quirk turns on "pci_use_crs" by
default on a board that needs it.
This fixes boot failures and oopses introduced in
3e3da00c01d0
("x86/pci: AMD one chain system to use pci read out res"). The quirk
is quite targetted (to a specific board and BIOS version) for two
reasons:
(1) to emphasize that this method of tackling the problem one quirk
at a time is a little insane
(2) to give BIOS vendors an opportunity to use simpler tables and
allow us to return to generic behavior (whatever that happens to
be) with a later BIOS update
In other words, I am not at all happy with having quirks like this.
But it is even worse for the kernel not to work out of the box on
these machines, so...
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42619
Reported-by: Svante Signell <svante.signell@telia.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Frank Rowand [Tue, 10 Apr 2012 00:59:03 +0000 (17:59 -0700)]
modpost: Fix modpost license checking of vmlinux.o
commit
258f742635360175564e9470eb060ff4d4b984e7 upstream.
Commit
f02e8a6596b7 ("module: Sort exported symbols") sorts symbols
placing each of them in its own elf section. This sorting and merging
into the canonical sections are done by the linker.
Unfortunately modpost to generate Module.symvers file parses vmlinux.o
(which is not linked yet) and all modules object files (which aren't
linked yet). These aren't sanitized by the linker yet. That breaks
modpost that can't detect license properly for modules.
This patch makes modpost aware of the new exported symbols structure.
[ This above is a slightly corrected version of the explanation of the
problem, copied from commit
62a2635610db ("modpost: Fix modpost's
license checking V3"). That commit fixed the problem for module
object files, but not for vmlinux.o. This patch fixes modpost for
vmlinux.o. ]
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alessio Igor Bogani [Thu, 14 Jul 2011 06:51:16 +0000 (08:51 +0200)]
modpost: Fix modpost's license checking V3
commit
62a2635610dbc83c5e8d724e00941eee4d18c186 upstream.
The commit
f02e8a6 sorts symbols placing each of them in its own elf section.
The sorting and merging into the canonical sections are done by the linker.
Unfortunately modpost to generate Module.symvers file parses vmlinux
(already linked) and all modules object files (which aren't linked yet).
These aren't sanitized by the linker yet. That breaks modpost that can't
detect license properly for modules. This patch makes modpost aware of
the new exported symbols structure.
Thanks to Arnaud Lacombe <lacombar@gmail.com> and Anders Kaseorg
<andersk@ksplice.com> for providing useful suggestions about code.
This work was supported by a hardware donation from the CE Linux Forum.
Reported-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 4 Apr 2012 18:40:19 +0000 (11:40 -0700)]
sysctl: fix write access to dmesg_restrict/kptr_restrict
commit
620f6e8e855d6d447688a5f67a4e176944a084e8 upstream.
Commit
bfdc0b4 adds code to restrict access to dmesg_restrict,
however, it incorrectly alters kptr_restrict rather than
dmesg_restrict.
The original patch from Richard Weinberger
(https://lkml.org/lkml/2011/3/14/362) alters dmesg_restrict as
expected, and so the patch seems to have been misapplied.
This adds the CAP_SYS_ADMIN check to both dmesg_restrict and
kptr_restrict, since both are sensitive.
Reported-by: Phillip Lougher <plougher@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Acked-by: Richard Weinberger <richard@nod.at>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ludovic Desroches [Wed, 28 Mar 2012 10:28:33 +0000 (12:28 +0200)]
mmc: atmel-mci: correct data timeout computation
commit
66292ad92c6d3f2f1c137a1c826b331ca8595dfd upstream.
The HSMCI operates at a rate of up to Master Clock divided by two.
Moreover previous calculation can cause overflows and so wrong
timeouts.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wessel [Fri, 23 Mar 2012 14:35:05 +0000 (09:35 -0500)]
x86,kgdb: Fix DEBUG_RODATA limitation using text_poke()
commit
3751d3e85cf693e10e2c47c03c8caa65e171099b upstream.
There has long been a limitation using software breakpoints with a
kernel compiled with CONFIG_DEBUG_RODATA going back to 2.6.26. For
this particular patch, it will apply cleanly and has been tested all
the way back to 2.6.36.
The kprobes code uses the text_poke() function which accommodates
writing a breakpoint into a read-only page. The x86 kgdb code can
solve the problem similarly by overriding the default breakpoint
set/remove routines and using text_poke() directly.
The x86 kgdb code will first attempt to use the traditional
probe_kernel_write(), and next try using a the text_poke() function.
The break point install method is tracked such that the correct break
point removal routine will get called later on.
Cc: x86@kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Inspried-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wessel [Thu, 29 Mar 2012 22:41:24 +0000 (17:41 -0500)]
kgdbts: (2 of 2) fix single step awareness to work correctly with SMP
commit
23bbd8e346f1ef3fc1219c79cea53d8d52b207d8 upstream.
The do_fork and sys_open tests have never worked properly on anything
other than a UP configuration with the kgdb test suite. This is
because the test suite did not fully implement the behavior of a real
debugger. A real debugger tracks the state of what thread it asked to
single step and can correctly continue other threads of execution or
conditionally stop while waiting for the original thread single step
request to return.
Below is a simple method to cause a fatal kernel oops with the kgdb
test suite on a 2 processor ARM system:
while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
echo V1I1F100 > /sys/module/kgdbts/parameters/kgdbts
Very soon after starting the test the kernel will start warning with
messages like:
kgdbts: BP mismatch
c002487c expected
c0024878
------------[ cut here ]------------
WARNING: at drivers/misc/kgdbts.c:317 check_and_rewind_pc+0x9c/0xc4()
[<
c01f6520>] (check_and_rewind_pc+0x9c/0xc4)
[<
c01f595c>] (validate_simple_test+0x3c/0xc4)
[<
c01f60d4>] (run_simple_test+0x1e8/0x274)
The kernel will eventually recovers, but the test suite has completely
failed to test anything useful.
This patch implements behavior similar to a real debugger that does
not rely on hardware single stepping by using only software planted
breakpoints.
In order to mimic a real debugger, the kgdb test suite now tracks the
most recent thread that was continued (cont_thread_id), with the
intent to single step just this thread. When the response to the
single step request stops in a different thread that hit the original
break point that thread will now get continued, while the debugger
waits for the thread with the single step pending. Here is a high
level description of the sequence of events.
cont_instead_of_sstep = 0;
1) set breakpoint at do_fork
2) continue
3) Save the thread id where we stop to cont_thread_id
4) Remove breakpoint at do_fork
5) Reset the PC if needed depending on kernel exception type
6) soft single step
7) Check where we stopped
if current thread != cont_thread_id {
if (here for more than 2 times for the same thead) {
### must be a really busy system, start test again ###
goto step 1
}
goto step 5
} else {
cont_instead_of_sstep = 0;
}
8) clean up and run test again if needed
9) Clear out any threads that were waiting on a break point at the
point in time the test is ended with get_cont_catch(). This
happens sometimes because breakpoints are used in place of single
stepping and some threads could have been in the debugger exception
handling queue because breakpoints were hit concurrently on
different CPUs. This also means we wait at least one second before
unplumbing the debugger connection at the very end, so as respond
to any debug threads waiting to be serviced.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wessel [Thu, 29 Mar 2012 22:41:24 +0000 (17:41 -0500)]
kgdbts: (1 of 2) fix single step awareness to work correctly with SMP
commit
486c5987a00a89d56c2c04c506417ef8f823ca2e upstream.
The do_fork and sys_open tests have never worked properly on anything
other than a UP configuration with the kgdb test suite. This is
because the test suite did not fully implement the behavior of a real
debugger. A real debugger tracks the state of what thread it asked to
single step and can correctly continue other threads of execution or
conditionally stop while waiting for the original thread single step
request to return.
Below is a simple method to cause a fatal kernel oops with the kgdb
test suite on a 4 processor x86 system:
while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
while [ 1 ] ; do ls > /dev/null 2> /dev/null; done&
echo V1I1F1000 > /sys/module/kgdbts/parameters/kgdbts
Very soon after starting the test the kernel will oops with a message like:
kgdbts: BP mismatch
3b7da66480 expected
ffffffff8106a590
WARNING: at drivers/misc/kgdbts.c:303 check_and_rewind_pc+0xe0/0x100()
Call Trace:
[<
ffffffff812994a0>] check_and_rewind_pc+0xe0/0x100
[<
ffffffff81298945>] validate_simple_test+0x25/0xc0
[<
ffffffff81298f77>] run_simple_test+0x107/0x2c0
[<
ffffffff81298a18>] kgdbts_put_char+0x18/0x20
The warn will turn to a hard kernel crash shortly after that because
the pc will not get properly rewound to the right value after hitting
a breakpoint leading to a hard lockup.
This change is broken up into 2 pieces because archs that have hw
single stepping (2.6.26 and up) need different changes than archs that
do not have hw single stepping (3.0 and up). This change implements
the correct behavior for an arch that supports hw single stepping.
A minor defect was fixed where sys_open should be do_sys_open
for the sys_open break point test. This solves the problem of running
a 64 bit with a 32 bit user space. The sys_open() never gets called
when using the 32 bit file system for the kgdb testsuite because the
32 bit binaries invoke the compat_sys_open() call leading to the test
never completing.
In order to mimic a real debugger, the kgdb test suite now tracks the
most recent thread that was continued (cont_thread_id), with the
intent to single step just this thread. When the response to the
single step request stops in a different thread that hit the original
break point that thread will now get continued, while the debugger
waits for the thread with the single step pending. Here is a high
level description of the sequence of events.
cont_instead_of_sstep = 0;
1) set breakpoint at do_fork
2) continue
3) Save the thread id where we stop to cont_thread_id
4) Remove breakpoint at do_fork
5) Reset the PC if needed depending on kernel exception type
6) if (cont_instead_of_sstep) { continue } else { single step }
7) Check where we stopped
if current thread != cont_thread_id {
cont_instead_of_sstep = 1;
goto step 5
} else {
cont_instead_of_sstep = 0;
}
8) clean up and run test again if needed
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wessel [Thu, 29 Mar 2012 11:55:44 +0000 (06:55 -0500)]
kgdbts: Fix kernel oops with CONFIG_DEBUG_RODATA
commit
456ca7ff24841bf2d2a2dfd690fe7d42ef70d932 upstream.
On x86 the kgdb test suite will oops when the kernel is compiled with
CONFIG_DEBUG_RODATA and you run the tests after boot time. This is
regression has existed since 2.6.26 by commit:
b33cb815 (kgdbts: Use
HW breakpoints with CONFIG_DEBUG_RODATA).
The test suite can use hw breakpoints for all the tests, but it has to
execute the hardware breakpoint specific tests first in order to
determine that the hw breakpoints actually work. Specifically the
very first test causes an oops:
# echo V1I1 > /sys/module/kgdbts/parameters/kgdbts
kgdb: Registered I/O driver kgdbts.
kgdbts:RUN plant and detach test
Entering kdb (current=0xffff880017aa9320, pid 1078) on processor 0 due to Keyboard Entry
[0]kdb> kgdbts: ERROR PUT: end of test buffer on 'plant_and_detach_test' line 1 expected OK got $E14#aa
WARNING: at drivers/misc/kgdbts.c:730 run_simple_test+0x151/0x2c0()
[...oops clipped...]
This commit re-orders the running of the tests and puts the RODATA
check into its own function so as to correctly avoid the kernel oops
by detecting and using the hw breakpoints.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wessel [Wed, 21 Mar 2012 15:17:03 +0000 (10:17 -0500)]
kgdb,debug_core: pass the breakpoint struct instead of address and memory
commit
98b54aa1a2241b59372468bd1e9c2d207bdba54b upstream.
There is extra state information that needs to be exposed in the
kgdb_bpt structure for tracking how a breakpoint was installed. The
debug_core only uses the the probe_kernel_write() to install
breakpoints, but this is not enough for all the archs. Some arch such
as x86 need to use text_poke() in order to install a breakpoint into a
read only page.
Passing the kgdb_bpt structure to kgdb_arch_set_breakpoint() and
kgdb_arch_remove_breakpoint() allows other archs to set the type
variable which indicates how the breakpoint was installed.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Sat, 24 Mar 2012 22:51:30 +0000 (23:51 +0100)]
drm/i915: quirk away broken OpRegion VBT
commit
25e341cfc33d94435472983825163e97fe370a6c upstream.
Somehow the BIOS manages to screw things up when copying the VBT
around, because the one we scrap from the VBIOS rom actually works.
Tested-by: Markus Heinz <markus.heinz@uni-dortmund.de>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sean Paul [Fri, 23 Mar 2012 12:52:58 +0000 (08:52 -0400)]
drm/i915: Add lock on drm_helper_resume_force_mode
commit
927a2f119e8235238a2fc64871051b16c9bdae75 upstream.
i915_drm_thaw was not locking the mode_config lock when calling
drm_helper_resume_force_mode. When there were multiple wake sources,
this caused FDI training failure on SNB which in turn corrupted the
display.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Thu, 22 Mar 2012 15:00:50 +0000 (15:00 +0000)]
drm/i915: Sanitize BIOS debugging bits from PIPECONF
commit
f47166d2b0001fcb752b40c5a2d4db986dfbea68 upstream.
Quoting the BSpec from time immemorial:
PIPEACONF, bits 28:27: Frame Start Delay (Debug)
Used to delay the frame start signal that is sent to the display planes.
Care must be taken to insure that there are enough lines during VBLANK
to support this setting.
An instance of the BIOS leaving these bits set was found in the wild,
where it caused our modesetting to go all squiffy and skewiff.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47271
Reported-and-tested-by: Eva Wang <evawang@linpus.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012
Reported-and-tested-by: Carl Richell <carl@system76.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anisse Astier [Wed, 7 Mar 2012 17:36:35 +0000 (18:36 +0100)]
drm/i915: no-lvds quirk on MSI DC500
commit
97effadb65ed08809e1720c8d3ee80b73a93665c upstream.
This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
LVDS detection.
Signed-off-by: Anisse Astier <anisse@astier.eu>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Thu, 29 Mar 2012 23:04:08 +0000 (19:04 -0400)]
drm/radeon/kms: fix fans after resume
commit
402976fe51b2d1a58a29ba06fa1ca5ace3a4cdcd upstream.
On pre-R600 asics, the SpeedFanControl table is not
executed as part of ASIC_Init as it is on newer asics.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=29412
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Mon, 26 Mar 2012 20:15:53 +0000 (21:15 +0100)]
drm: Validate requested virtual size against allocated fb size
commit
62fb376e214d3c1bfdf6fbb77dac162f6da04d7e upstream.
mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for "doublebuffering". By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these users, we should therefore reject any userspace request to
create a screen that requires a buffer larger than the framebuffer
originally allocated.
References: https://bugs.freedesktop.org/show_bug.cgi?id=38138
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Mon, 19 Mar 2012 15:00:26 +0000 (16:00 +0100)]
mac80211: fix possible tid_rx->reorder_timer use after free
commit
d72308bff5c2fa207949a5925b020bce74495e33 upstream.
Is possible that we will arm the tid_rx->reorder_timer after
del_timer_sync() in ___ieee80211_stop_rx_ba_session(). We need to stop
timer after RCU grace period finish, so move it to
ieee80211_free_tid_rx(). Timer will not be armed again, as
rcu_dereference(sta->ampdu_mlme.tid_rx[tid]) will return NULL.
Debug object detected problem with the following warning:
ODEBUG: free active (active state 0) object type: timer_list hint: sta_rx_agg_reorder_timer_expired+0x0/0xf0 [mac80211]
Bug report (with all warning messages):
https://bugzilla.redhat.com/show_bug.cgi?id=804007
Reported-by: "jan p. springer" <jsd@igroup.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Sun, 18 Mar 2012 12:21:38 +0000 (13:21 +0100)]
m68k/mac: Add missing platform check before registering platform devices
commit
6cfeba53911d6d2f17ebbd1246893557d5ff5aeb upstream.
On multi-platform kernels, the Mac platform devices should be registered
when running on Mac only. Else it may crash later.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wolfgang Mauerer [Thu, 22 Mar 2012 10:18:20 +0000 (11:18 +0100)]
tracing: Fix ftrace stack trace entries
commit
01de982abf8c9e10fc3089e10585cd2cc914bdab upstream.
8 hex characters tell only half the tale for 64 bit CPUs,
so use the appropriate length.
Link: http://lkml.kernel.org/r/1332411501-8059-2-git-send-email-wolfgang.mauerer@siemens.com
Signed-off-by: Wolfgang Mauerer <wolfgang.mauerer@siemens.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiang Liu [Fri, 30 Mar 2012 15:11:33 +0000 (23:11 +0800)]
genirq: Adjust irq thread affinity on IRQ_SET_MASK_OK_NOCOPY return value
commit
f5cb92ac82d06cb583c1f66666314c5c0a4d7913 upstream.
irq_move_masked_irq() checks the return code of
chip->irq_set_affinity() only for 0, but IRQ_SET_MASK_OK_NOCOPY is
also a valid return code, which is there to avoid a redundant copy of
the cpumask. But in case of IRQ_SET_MASK_OK_NOCOPY we not only avoid
the redundant copy, we also fail to adjust the thread affinity of an
eventually threaded interrupt handler.
Handle IRQ_SET_MASK_OK (==0) and IRQ_SET_MASK_OK_NOCOPY(==1) return
values correctly by checking the valid return values seperately.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Jiang Liu <liuj97@gmail.com>
Cc: Keping Chen <chenkeping@huawei.com>
Link: http://lkml.kernel.org/r/1333120296-13563-2-git-send-email-jiang.liu@huawei.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Beulich [Thu, 8 Mar 2012 09:41:25 +0000 (09:41 +0000)]
modpost: fix ALL_INIT_DATA_SECTIONS
commit
9aaf440f8fabcebf9ea79a62ccf4c212e6544b49 upstream.
This was lacking a comma between two supposed to be separate strings.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Julian Anastasov [Thu, 23 Feb 2012 20:40:43 +0000 (22:40 +0200)]
ACPICA: Fix regression in FADT revision checks
commit
3e80acd1af40fcd91a200b0416a7616b20c5d647 upstream.
commit
64b3db22c04586997ab4be46dd5a5b99f8a2d390 (2.6.39),
"Remove use of unreliable FADT revision field" causes regression
for old P4 systems because now cst_control and other fields are
not reset to 0.
The effect is that acpi_processor_power_init will notice
cst_control != 0 and a write to CST_CNT register is performed
that should not happen. As result, the system oopses after the
"No _CST, giving up" message, sometimes in acpi_ns_internalize_name,
sometimes in acpi_ns_get_type, usually at random places. May be
during migration to CPU 1 in acpi_processor_get_throttling.
Every one of these settings help to avoid this problem:
- acpi=off
- processor.nocst=1
- maxcpus=1
The fix is to update acpi_gbl_FADT.header.length after
the original value is used to check for old revisions.
https://bugzilla.kernel.org/show_bug.cgi?id=42700
https://bugzilla.redhat.com/show_bug.cgi?id=727865
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Acked-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Cc: Josh Boyer <jwboyer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yinghai Lu [Sat, 3 Mar 2012 21:29:20 +0000 (13:29 -0800)]
PNPACPI: Fix device ref leaking in acpi_pnp_match
commit
89e96ada572fb216e582dbe3f64e1a6939a37f74 upstream.
During testing pci root bus removal, found some root bus bridge is not freed.
If booting with pnpacpi=off, those hostbridge could be freed without problem.
It turns out that some devices reference are not released during acpi_pnp_match.
that match should not hold one device ref during every calling.
Add pu_device calling before returning.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andi Kleen [Mon, 6 Feb 2012 16:17:11 +0000 (08:17 -0800)]
ACPI: Do cpufreq clamping for throttling per package v2
commit
2815ab92ba3ab27556212cc306288dc95692824b upstream.
On Intel CPUs the processor typically uses the highest frequency
set by any logical CPU. When the system overheats
Linux first forces the frequency to the lowest available one
to lower the temperature.
However this was done only per logical CPU, which means all
logical CPUs in a package would need to go through this before
the frequency is actually lowered.
Worse this delay actually prevents real throttling, because
the real throttle code only proceeds when the lowest frequency
is already reached.
So when a throttle event happens force the lowest frequency
for all CPUs in the package where it happened. The per CPU
state is now kept per package, not per logical CPU. An alternative
would be to do it per cpufreq unit, but since we want to bring
down the temperature of the complete chip it's better
to do it for all.
In principle it may even make sense to do it for all CPUs,
but I kept it on the package for now.
With this change the frequency is actually lowered, which
in terms also allows real throttling to proceed.
I also removed an unnecessary per cpu variable initialization.
v2: Fix package mapping
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Norris [Tue, 31 Jan 2012 08:06:03 +0000 (00:06 -0800)]
mtd: m25p80: set writebufsize
commit
b54f47c8bcfc5f766bf13ec31bd7dd1d4726d33b upstream.
Using UBI on m25p80 can give messages like:
UBI error: io_init: bad write buffer size 0 for 1 min. I/O unit
We need to initialize writebufsize; I think "page_size" is the correct
"bufsize", although I'm not sure. Comments?
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Artem Bityutskiy [Fri, 3 Feb 2012 07:53:28 +0000 (09:53 +0200)]
mtd: lart: initialize writebufsize
commit
fcc44a07dae0af16e84e93425fc8afe642ddc603 upstream.
The writebufsize concept was introduce by commit
"
0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.
Set writebufsize to 4 because this drivers writes at max 4 bytes at a time.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Artem Bityutskiy [Fri, 3 Feb 2012 07:32:44 +0000 (09:32 +0200)]
mtd: block2mtd: initialize writebufsize
commit
b604387411ec6a072e95910099262616edd2bd2f upstream.
The writebufsize concept was introduce by commit
"
0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.
However, we forgot to set this parameter for block2mtd. Set it to PAGE_SIZE
because this is actually the amount of data we write at a time.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Acked-by: Joern Engel <joern@lazybastard.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Artem Bityutskiy [Fri, 3 Feb 2012 08:16:50 +0000 (10:16 +0200)]
mtd: sst25l: initialize writebufsize
commit
c4cc625ea5958d065c21cc0fcea29e9ed8f3d2bc upstream.
The writebufsize concept was introduce by commit
"
0e4ca7e mtd: add writebufsize field to mtd_info struct" and it represents
the maximum amount of data the device writes to the media at a time. This is
an important parameter for UBIFS which is used during recovery and which
basically defines how big a corruption caused by a power cut can be.
Set writebufsize to the flash page size because it is the maximum amount of
data it writes at a time.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rabin Vincent [Thu, 29 Mar 2012 07:15:15 +0000 (07:15 +0000)]
net: usb: cdc_eem: fix mtu
[ Upstream commit
78fb72f7936c01d5b426c03a691eca082b03f2b9 ]
Make CDC EEM recalculate the hard_mtu after adjusting the
hard_header_len.
Without this, usbnet adjusts the MTU down to 1494 bytes, and the host is
unable to receive standard 1500-byte frames from the device.
Tested with the Linux USB Ethernet gadget.
Cc: Oliver Neukum <oliver@neukum.name>
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
danborkmann@iogearbox.net [Tue, 27 Mar 2012 22:47:43 +0000 (22:47 +0000)]
rose_dev: fix memcpy-bug in rose_set_mac_address
[ Upstream commit
81213b5e8ae68e204aa7a3f83c4f9100405dbff9 ]
If both addresses equal, nothing needs to be done. If the device is down,
then we simply copy the new address to dev->dev_addr. If the device is up,
then we add another loopback device with the new address, and if that does
not fail, we remove the loopback device with the old address. And only
then, we update the dev->dev_addr.
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
zhuangfeiran@ict.ac.cn [Wed, 28 Mar 2012 23:27:00 +0000 (23:27 +0000)]
x86 bpf_jit: fix a bug in emitting the 16-bit immediate operand of AND
[ Upstream commit
1d24fb3684f347226747c6b11ea426b7b992694e ]
When K >= 0xFFFF0000, AND needs the two least significant bytes of K as
its operand, but EMIT2() gives it the least significant byte of K and
0x2. EMIT() should be used here to replace EMIT2().
Signed-off-by: Feiran Zhuang <zhuangfeiran@ict.ac.cn>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Mon, 2 Apr 2012 16:28:56 +0000 (09:28 -0700)]
Linux 3.0.27
Matthew Garrett [Tue, 27 Mar 2012 14:17:41 +0000 (10:17 -0400)]
ASPM: Fix pcie devices with non-pcie children
commit
c9651e70ad0aa499814817cbf3cc1d0b806ed3a1 upstream.
Since 3.2.12 and 3.3, some systems are failing to boot with a BUG_ON.
Some other systems using the pata_jmicron driver fail to boot because no
disks are detected. Passing pcie_aspm=force on the kernel command line
works around it.
The cause: commit
4949be16822e ("PCI: ignore pre-1.1 ASPM quirking when
ASPM is disabled") changed the behaviour of pcie_aspm_sanity_check() to
always return 0 if aspm is disabled, in order to avoid cases where we
changed ASPM state on pre-PCIe 1.1 devices.
This skipped the secondary function of pcie_aspm_sanity_check which was
to avoid us enabling ASPM on devices that had non-PCIe children, causing
trouble later on. Move the aspm_disabled check so we continue to honour
that scenario.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=42979 and
http://bugs.debian.org/665420
Reported-by: Romain Francoise <romain@orebokech.com> # kernel panic
Reported-by: Chris Holland <bandidoirlandes@gmail.com> # disk detection trouble
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Tested-by: Hatem Masmoudi <hatem.masmoudi@gmail.com> # Dell Latitude E5520
Tested-by: janek <jan0x6c@gmail.com> # pata_jmicron with JMB362/JMB363
[jn: with more symptoms in log message]
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yoshii Takashi [Wed, 14 Mar 2012 07:14:43 +0000 (16:14 +0900)]
serial: sh-sci: fix a race of DMA submit_tx on transfer
commit
49d4bcaddca977fffdea8b0b71f6e5da96dac78e upstream.
When DMA is enabled, sh-sci transfer begins with
uart_start()
sci_start_tx()
if (cookie_tx < 0) schedule_work()
Then, starts DMA when wq scheduled, -- (A)
process_one_work()
work_fn_rx()
cookie_tx = desc->submit_tx()
And finishes when DMA transfer ends, -- (B)
sci_dma_tx_complete()
async_tx_ack()
cookie_tx = -EINVAL
(possible another schedule_work())
This A to B sequence is not reentrant, since controlling variables
(for example, cookie_tx above) are not queues nor lists. So, they
must be invoked as A B A B..., otherwise results in kernel crash.
To ensure the sequence, sci_start_tx() seems to test if cookie_tx < 0
(represents "not used") to call schedule_work().
But cookie_tx will not be set (to a cookie, also means "used") until
in the middle of work queue scheduled function work_fn_tx().
This gap between the test and set allows the breakage of the sequence
under the very frequently call of uart_start().
Another gap between async_tx_ack() and another schedule_work() results
in the same issue, too.
This patch introduces a new condition "cookie_tx == 0" just to mark
it is "busy" and assign it within spin-locked region to fill the gaps.
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Reviewed-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Wed, 18 Jan 2012 09:56:02 +0000 (12:56 +0300)]
nfsd: don't allow zero length strings in cache_parse()
commit
6d8d17499810479eabd10731179c04b2ca22152f upstream.
There is no point in passing a zero length string here and quite a
few of that cache_parse() implementations will Oops if count is
zero.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Metcalf [Mon, 26 Mar 2012 20:26:12 +0000 (16:26 -0400)]
compat: use sys_sendfile64() implementation for sendfile syscall
commit
1631fcea8399da5e80a80084b3b8c5bfd99d21e7 upstream.
<asm-generic/unistd.h> was set up to use sys_sendfile() for the 32-bit
compat API instead of sys_sendfile64(), but in fact the right thing to
do is to use sys_sendfile64() in all cases. The 32-bit sendfile64() API
in glibc uses the sendfile64 syscall, so it has to be capable of doing
full 64-bit operations. But the sys_sendfile() kernel implementation
has a MAX_NON_LFS test in it which explicitly limits the offset to 2^32.
So, we need to use the sys_sendfile64() implementation in the kernel
for this case.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Sat, 24 Mar 2012 07:52:50 +0000 (10:52 +0300)]
x86, tls: Off by one limit check
commit
8f0750f19789cf352d7e24a6cc50f2ab1b4f1372 upstream.
These are used as offsets into an array of GDT_ENTRY_TLS_ENTRIES members
so GDT_ENTRY_TLS_ENTRIES is one past the end of the array.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: http://lkml.kernel.org/r/20120324075250.GA28258@elgon.mountain
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alok Kataria [Wed, 22 Feb 2012 02:19:55 +0000 (18:19 -0800)]
x86, tsc: Skip refined tsc calibration on systems with reliable TSC
commit
57779dc2b3b75bee05ef5d1ada47f615f7a13932 upstream.
While running the latest Linux as guest under VMware in highly
over-committed situations, we have seen cases when the refined TSC
algorithm fails to get a valid tsc_start value in
tsc_refine_calibration_work from multiple attempts. As a result the
kernel keeps on scheduling the tsc_irqwork task for later. Subsequently
after several attempts when it gets a valid start value it goes through
the refined calibration and either bails out or uses the new results.
Given that the kernel originally read the TSC frequency from the
platform, which is the best it can get, I don't think there is much
value in refining it.
So for systems which get the TSC frequency from the platform we
should skip the refined tsc algorithm.
We can use the TSC_RELIABLE cpu cap flag to detect this, right now it is
set only on VMware and for Moorestown Penwell both of which have there
own TSC calibration methods.
Signed-off-by: Alok N Kataria <akataria@vmware.com>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Dirk Brandewie <dirk.brandewie@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
[jstultz: Reworked to simply not schedule the refining work,
rather then scheduling the work and bombing out later]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Tue, 7 Feb 2012 04:35:42 +0000 (15:35 +1100)]
lockd: fix arg parsing for grace_period and timeout.
commit
de5b8e8e047534aac6bc9803f96e7257436aef9c upstream.
If you try to set grace_period or timeout via a module parameter
to lockd, and do this on a big-endian machine where
sizeof(int) != sizeof(unsigned long)
it won't work. This number given will be effectively shifted right
by the difference in those two sizes.
So cast kp->arg properly to get correct result.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steffen Klassert [Wed, 21 Mar 2012 23:36:13 +0000 (23:36 +0000)]
xfrm: Access the replay notify functions via the registered callbacks
[ Upstream commit
1265fd616782ef03b98fd19f65c2b47fcd4ea11f ]
We call the wrong replay notify function when we use ESN replay
handling. This leads to the fact that we don't send notifications
if we use ESN. Fix this by calling the registered callbacks instead
of xfrm_replay_notify().
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
stephen hemminger [Wed, 21 Mar 2012 05:32:05 +0000 (05:32 +0000)]
sky2: override for PCI legacy power management
[ Upstream commit
5676cc7bfe1e388e87843f71daa229610385b41e ]
Some BIOS's don't setup power management correctly (what else is
new) and don't allow use of PCI Express power control. Add a special
exception module parameter to allow working around this issue.
Based on slightly different patch by Knut Petersen.
Reported-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Jones [Mon, 19 Mar 2012 13:01:07 +0000 (13:01 +0000)]
Remove printk from rds_sendmsg
[ Upstream commit
a6506e1486181975d318344143aca722b2b91621 ]
no socket layer outputs a message for this error and neither should rds.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>