Mark Hills [Mon, 30 Apr 2012 18:39:22 +0000 (19:39 +0100)]
ALSA: echoaudio: Remove incorrect part of assertion
commit
c914f55f7cdfafe9d7d5b248751902c7ab57691e upstream.
This assertion seems to imply that chip->dsp_code_to_load is a pointer.
It's actually an integer handle on the actual firmware, and 0 has no
special meaning.
The assertion prevents initialisation of a Darla20 card, but would also
affect other models. It seems it was introduced in commit
dd7b254d.
ALSA sound/pci/echoaudio/echoaudio.c:2061 Echoaudio driver starting...
ALSA sound/pci/echoaudio/echoaudio.c:1969 chip=
ebe4e000
ALSA sound/pci/echoaudio/echoaudio.c:2007 pci=
ed568000 irq=19 subdev=0010 Init hardware...
ALSA sound/pci/echoaudio/darla20_dsp.c:36 init_hw() - Darla20
------------[ cut here ]------------
WARNING: at sound/pci/echoaudio/echoaudio_dsp.c:478 init_hw+0x1d1/0x86c [snd_darla20]()
Hardware name: Dell DM051
BUG? (!chip->dsp_code_to_load || !chip->comm_page)
Signed-off-by: Mark Hills <mark@pogo.org.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Eric Dumazet [Sun, 29 Apr 2012 09:08:22 +0000 (09:08 +0000)]
netem: fix possible skb leak
[ Upstream commit
116a0fc31c6c9b8fc821be5a96e5bf0b43260131 ]
skb_checksum_help(skb) can return an error, we must free skb in this
case. qdisc_drop(skb, sch) can also be feeded with a NULL skb (if
skb_unshare() failed), so lets use this generic helper.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Tim Bird [Wed, 2 May 2012 21:55:39 +0000 (22:55 +0100)]
ARM: 7410/1: Add extra clobber registers for assembly in kernel_execve
commit
e787ec1376e862fcea1bfd523feb7c5fb43ecdb9 upstream.
The inline assembly in kernel_execve() uses r8 and r9. Since this
code sequence does not return, it usually doesn't matter if the
register clobber list is accurate. However, I saw a case where a
particular version of gcc used r8 as an intermediate for the value
eventually passed to r9. Because r8 is used in the inline
assembly, and not mentioned in the clobber list, r9 was set
to an incorrect value.
This resulted in a kernel panic on execution of the first user-space
program in the system. r9 is used in ret_to_user as the thread_info
pointer, and if it's wrong, bad things happen.
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
David Ward [Sun, 15 Apr 2012 12:31:45 +0000 (12:31 +0000)]
net_sched: gred: Fix oops in gred_dump() in WRED mode
[ Upstream commit
244b65dbfede788f2fa3fe2463c44d0809e97c6b ]
A parameter set exists for WRED mode, called wred_set, to hold the same
values for qavg and qidlestart across all VQs. The WRED mode values had
been previously held in the VQ for the default DP. After these values
were moved to wred_set, the VQ for the default DP was no longer created
automatically (so that it could be omitted on purpose, to have packets
in the default DP enqueued directly to the device without using RED).
However, gred_dump() was overlooked during that change; in WRED mode it
still reads qavg/qidlestart from the VQ for the default DP, which might
not even exist. As a result, this command sequence will cause an oops:
tc qdisc add dev $DEV handle $HANDLE parent $PARENT gred setup \
DPs 3 default 2 grio
tc qdisc change dev $DEV handle $HANDLE gred DP 0 prio 8 $RED_OPTIONS
tc qdisc change dev $DEV handle $HANDLE gred DP 1 prio 8 $RED_OPTIONS
This fixes gred_dump() in WRED mode to use the values held in wred_set.
Signed-off-by: David Ward <david.ward@ll.mit.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Davide Ciminaghi [Fri, 13 Apr 2012 04:48:25 +0000 (04:48 +0000)]
net/ethernet: ks8851_mll fix rx frame buffer overflow
[ Upstream commit
8a9a0ea6032186e3030419262678d652b88bf6a8 ]
At the beginning of ks_rcv(), a for loop retrieves the
header information relevant to all the frames stored
in the mac's internal buffers. The number of pending
frames is stored as an 8 bits field in KS_RXFCTR.
If interrupts are disabled long enough to allow for more than
32 frames to accumulate in the MAC's internal buffers, a buffer
overflow occurs.
This patch fixes the problem by making the
driver's frame_head_info buffer big enough.
Well actually, since the chip appears to have 12K of
internal rx buffers and the shortest ethernet frame should
be 64 bytes long, maybe the limit could be set to
12*1024/64 = 192 frames, but 255 should be safer.
Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com>
Signed-off-by: Raffaele Recalcati <raffaele.recalcati@bticino.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Tony Zelenoff [Wed, 11 Apr 2012 06:15:03 +0000 (06:15 +0000)]
atl1: fix kernel panic in case of DMA errors
[ Upstream commit
03662e41c7cff64a776bfb1b3816de4be43de881 ]
Problem:
There was two separate work_struct structures which share one
handler. Unfortunately getting atl1_adapter structure from
work_struct in case of DMA error was done from incorrect
offset which cause kernel panics.
Solution:
The useless work_struct for DMA error removed and
handler name changed to more generic one.
Signed-off-by: Tony Zelenoff <antonz@parallels.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Eric Dumazet [Fri, 6 Apr 2012 08:49:10 +0000 (10:49 +0200)]
net: fix a race in sock_queue_err_skb()
[ Upstream commit
110c43304db6f06490961529536c362d9ac5732f ]
As soon as an skb is queued into socket error queue, another thread
can consume it, so we are not allowed to reference skb anymore, or risk
use after free.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Eric Dumazet [Thu, 5 Apr 2012 22:17:46 +0000 (22:17 +0000)]
netlink: fix races after skb queueing
[ Upstream commit
4a7e7c2ad540e54c75489a70137bf0ec15d3a127 ]
As soon as an skb is queued into socket receive_queue, another thread
can consume it, so we are not allowed to reference skb anymore, or risk
use after free.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Sasha Levin [Thu, 5 Apr 2012 12:07:45 +0000 (12:07 +0000)]
phonet: Check input from user before allocating
[ Upstream commit
bcf1b70ac6eb0ed8286c66e6bf37cb747cbaa04c ]
A phonet packet is limited to USHRT_MAX bytes, this is never checked during
tx which means that the user can specify any size he wishes, and the kernel
will attempt to allocate that size.
In the good case, it'll lead to the following warning, but it may also cause
the kernel to kick in the OOM and kill a random task on the server.
[ 8921.744094] WARNING: at mm/page_alloc.c:2255 __alloc_pages_slowpath+0x65/0x730()
[ 8921.749770] Pid: 5081, comm: trinity Tainted: G W 3.4.0-rc1-next-
20120402-sasha #46
[ 8921.756672] Call Trace:
[ 8921.758185] [<
ffffffff810b2ba7>] warn_slowpath_common+0x87/0xb0
[ 8921.762868] [<
ffffffff810b2be5>] warn_slowpath_null+0x15/0x20
[ 8921.765399] [<
ffffffff8117eae5>] __alloc_pages_slowpath+0x65/0x730
[ 8921.769226] [<
ffffffff81179c8a>] ? zone_watermark_ok+0x1a/0x20
[ 8921.771686] [<
ffffffff8117d045>] ? get_page_from_freelist+0x625/0x660
[ 8921.773919] [<
ffffffff8117f3a8>] __alloc_pages_nodemask+0x1f8/0x240
[ 8921.776248] [<
ffffffff811c03e0>] kmalloc_large_node+0x70/0xc0
[ 8921.778294] [<
ffffffff811c4bd4>] __kmalloc_node_track_caller+0x34/0x1c0
[ 8921.780847] [<
ffffffff821b0e3c>] ? sock_alloc_send_pskb+0xbc/0x260
[ 8921.783179] [<
ffffffff821b3c65>] __alloc_skb+0x75/0x170
[ 8921.784971] [<
ffffffff821b0e3c>] sock_alloc_send_pskb+0xbc/0x260
[ 8921.787111] [<
ffffffff821b002e>] ? release_sock+0x7e/0x90
[ 8921.788973] [<
ffffffff821b0ff0>] sock_alloc_send_skb+0x10/0x20
[ 8921.791052] [<
ffffffff824cfc20>] pep_sendmsg+0x60/0x380
[ 8921.792931] [<
ffffffff824cb4a6>] ? pn_socket_bind+0x156/0x180
[ 8921.794917] [<
ffffffff824cb50f>] ? pn_socket_autobind+0x3f/0x90
[ 8921.797053] [<
ffffffff824cb63f>] pn_socket_sendmsg+0x4f/0x70
[ 8921.798992] [<
ffffffff821ab8e7>] sock_aio_write+0x187/0x1b0
[ 8921.801395] [<
ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
[ 8921.803501] [<
ffffffff8111842c>] ? __lock_acquire+0x42c/0x4b0
[ 8921.805505] [<
ffffffff821ab760>] ? __sock_recv_ts_and_drops+0x140/0x140
[ 8921.807860] [<
ffffffff811e07cc>] do_sync_readv_writev+0xbc/0x110
[ 8921.809986] [<
ffffffff811958e7>] ? might_fault+0x97/0xa0
[ 8921.811998] [<
ffffffff817bd99e>] ? security_file_permission+0x1e/0x90
[ 8921.814595] [<
ffffffff811e17e2>] do_readv_writev+0xe2/0x1e0
[ 8921.816702] [<
ffffffff810b8dac>] ? do_setitimer+0x1ac/0x200
[ 8921.818819] [<
ffffffff810e2ec1>] ? get_parent_ip+0x11/0x50
[ 8921.820863] [<
ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
[ 8921.823318] [<
ffffffff811e1926>] vfs_writev+0x46/0x60
[ 8921.825219] [<
ffffffff811e1a3f>] sys_writev+0x4f/0xb0
[ 8921.827127] [<
ffffffff82658039>] system_call_fastpath+0x16/0x1b
[ 8921.829384] ---[ end trace
dffe390f30db9eb7 ]---
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Thomas Jarosch [Wed, 7 Dec 2011 21:08:11 +0000 (22:08 +0100)]
PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs
commit
f67fd55fa96f7d7295b43ffbc4a97d8f55e473aa upstream.
Some BIOS implementations leave the Intel GPU interrupts enabled,
even though no one is handling them (f.e. i915 driver is never loaded).
Additionally the interrupt destination is not set up properly
and the interrupt ends up -somewhere-.
These spurious interrupts are "sticky" and the kernel disables
the (shared) interrupt line after 100.000+ generated interrupts.
Fix it by disabling the still enabled interrupts.
This resolves crashes often seen on monitor unplug.
Tested on the following boards:
- Intel DH61CR: Affected
- Intel DH67BL: Affected
- Intel S1200KP server board: Affected
- Asus P8H61-M LE: Affected, but system does not crash.
Probably the IRQ ends up somewhere unnoticed.
According to reports on the net, the Intel DH61WW board is also affected.
Many thanks to Jesse Barnes from Intel for helping
with the register configuration and to Intel in general
for providing public hardware documentation.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Tested-by: Charlie Suffin <charlie.suffin@stratus.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Kent Yoder [Thu, 5 Apr 2012 12:34:20 +0000 (20:34 +0800)]
crypto: sha512 - Fix byte counter overflow in SHA-512
commit
25c3d30c918207556ae1d6e663150ebdf902186b upstream.
The current code only increments the upper 64 bits of the SHA-512 byte
counter when the number of bytes hashed happens to hit 2^64 exactly.
This patch increments the upper 64 bits whenever the lower 64 bits
overflows.
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
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>
Signed-off-by: Willy Tarreau <w@1wt.eu>
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>
Signed-off-by: Willy Tarreau <w@1wt.eu>
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>
Signed-off-by: Willy Tarreau <w@1wt.eu>
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>
Signed-off-by: Willy Tarreau <w@1wt.eu>
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>
Signed-off-by: Willy Tarreau <w@1wt.eu>
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>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jun Nie [Tue, 7 Dec 2010 06:03:38 +0000 (14:03 +0800)]
Bluetooth: add NULL pointer check in HCI
commit
d9319560b86839506c2011346b1f2e61438a3c73 upstream.
If we fail to find a hci device pointer in hci_uart, don't try
to deref the NULL one we do have.
Signed-off-by: Jun Nie <njun@marvell.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Willy Tarreau <w@1wt.eu>
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>
Signed-off-by: Willy Tarreau <w@1wt.eu>
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>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jan Kara [Thu, 15 Mar 2012 09:34:02 +0000 (09:34 +0000)]
xfs: Fix oops on IO error during xlog_recover_process_iunlinks()
commit
d97d32edcd732110758799ae60af725e5110b3dc upstream.
When an IO error happens during inode deletion run from
xlog_recover_process_iunlinks() filesystem gets shutdown. Thus any subsequent
attempt to read buffers fails. Code in xlog_recover_process_iunlinks() does not
count with the fact that read of a buffer which was read a while ago can
really fail which results in the oops on
agi = XFS_BUF_TO_AGI(agibp);
Fix the problem by cleaning up the buffer handling in
xlog_recover_process_iunlinks() as suggested by Dave Chinner. We release buffer
lock but keep buffer reference to AG buffer. That is enough for buffer to stay
pinned in memory and we don't have to call xfs_read_agi() all the time.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Theodore Ts'o [Mon, 12 Mar 2012 03:30:16 +0000 (23:30 -0400)]
ext4: check for zero length extent
commit
31d4f3a2f3c73f279ff96a7135d7202ef6833f12 upstream.
Explicitly test for an extent whose length is zero, and flag that as a
corrupted extent.
This avoids a kernel BUG_ON assertion failure.
Tested: Without this patch, the file system image found in
tests/f_ext_zero_len/image.gz in the latest e2fsprogs sources causes a
kernel panic. With this patch, an ext4 file system error is noted
instead, and the file system is marked as being corrupted.
https://bugzilla.kernel.org/show_bug.cgi?id=42859
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Trond Myklebust [Mon, 19 Mar 2012 17:39:35 +0000 (13:39 -0400)]
SUNRPC: We must not use list_for_each_entry_safe() in rpc_wake_up()
commit
540a0f7584169651f485e8ab67461fcb06934e38 upstream.
The problem is that for the case of priority queues, we
have to assume that __rpc_remove_wait_queue_priority will move new
elements from the tk_wait.links lists into the queue->tasks[] list.
We therefore cannot use list_for_each_entry_safe() on queue->tasks[],
since that will skip these new tasks that __rpc_remove_wait_queue_priority
is adding.
Without this fix, rpc_wake_up and rpc_wake_up_status will both fail
to wake up all functions on priority wait queues, which can result
in some nasty hangs.
Reported-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Sasha Levin [Thu, 15 Mar 2012 16:36:14 +0000 (12:36 -0400)]
ntp: Fix integer overflow when setting time
commit
a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33 upstream.
'long secs' is passed as divisor to div_s64, which accepts a 32bit
divisor. On 64bit machines that value is trimmed back from 8 bytes
back to 4, causing a divide by zero when the number is bigger than
(1 << 32) - 1 and all 32 lower bits are 0.
Use div64_long() instead.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Cc: johnstul@us.ibm.com
Link: http://lkml.kernel.org/r/1331829374-31543-2-git-send-email-levinsasha928@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[WT: div64_long() does not exist on 2.6.32 and needs a deeper backport than
desired. Instead, address the issue by controlling that the divisor is
correct for use as an s32 divisor]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Greg Kroah-Hartman [Tue, 28 Feb 2012 17:20:09 +0000 (09:20 -0800)]
USB: ftdi_sio: fix problem when the manufacture is a NULL string
commit
656d2b3964a9d0f9864d472f8dfa2dd7dd42e6c0 upstream.
On some misconfigured ftdi_sio devices, if the manufacturer string is
NULL, the kernel will oops when the device is plugged in. This patch
fixes the problem.
Reported-by: Wojciech M Zabolotny <W.Zabolotny@elka.pw.edu.pl>
Tested-by: Wojciech M Zabolotny <W.Zabolotny@elka.pw.edu.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Ryusuke Konishi [Sat, 17 Mar 2012 00:08:39 +0000 (17:08 -0700)]
nilfs2: fix NULL pointer dereference in nilfs_load_super_block()
commit
d7178c79d9b7c5518f9943188091a75fc6ce0675 upstream.
According to the report from Slicky Devil, nilfs caused kernel oops at
nilfs_load_super_block function during mount after he shrank the
partition without resizing the filesystem:
BUG: unable to handle kernel NULL pointer dereference at
00000048
IP: [<
d0d7a08e>] nilfs_load_super_block+0x17e/0x280 [nilfs2]
*pde =
00000000
Oops: 0000 [#1] PREEMPT SMP
...
Call Trace:
[<
d0d7a87b>] init_nilfs+0x4b/0x2e0 [nilfs2]
[<
d0d6f707>] nilfs_mount+0x447/0x5b0 [nilfs2]
[<
c0226636>] mount_fs+0x36/0x180
[<
c023d961>] vfs_kern_mount+0x51/0xa0
[<
c023ddae>] do_kern_mount+0x3e/0xe0
[<
c023f189>] do_mount+0x169/0x700
[<
c023fa9b>] sys_mount+0x6b/0xa0
[<
c04abd1f>] sysenter_do_call+0x12/0x28
Code: 53 18 8b 43 20 89 4b 18 8b 4b 24 89 53 1c 89 43 24 89 4b 20 8b 43
20 c7 43 2c 00 00 00 00 23 75 e8 8b 50 68 89 53 28 8b 54 b3 20 <8b> 72
48 8b 7a 4c 8b 55 08 89 b3 84 00 00 00 89 bb 88 00 00 00
EIP: [<
d0d7a08e>] nilfs_load_super_block+0x17e/0x280 [nilfs2] SS:ESP 0068:
ca9bbdcc
CR2:
0000000000000048
This turned out due to a defect in an error path which runs if the
calculated location of the secondary super block was invalid.
This patch fixes it and eliminates the reported oops.
Reported-by: Slicky Devil <slicky.dvl@gmail.com>
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Tested-by: Slicky Devil <slicky.dvl@gmail.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>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dan Carpenter [Sat, 3 Mar 2012 11:09:17 +0000 (12:09 +0100)]
block, sx8: fix pointer math issue getting fw version
commit
ea5f4db8ece896c2ab9eafa0924148a2596c52e4 upstream.
"mem" is type u8. We need parenthesis here or it screws up the pointer
math probably leading to an oops.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Eric Dumazet [Thu, 23 Feb 2012 10:55:02 +0000 (10:55 +0000)]
ipsec: be careful of non existing mac headers
[ Upstream commit
03606895cd98c0a628b17324fd7b5ff15db7e3cd ]
Niccolo Belli reported ipsec crashes in case we handle a frame without
mac header (atm in his case)
Before copying mac header, better make sure it is present.
Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809
Reported-by: Niccolò Belli <darkbasic@linuxsystems.it>
Tested-by: Niccolò Belli <darkbasic@linuxsystems.it>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Thomas Gleixner [Fri, 9 Mar 2012 19:55:10 +0000 (20:55 +0100)]
x86: Derandom delay_tsc for 64 bit
commit
a7f4255f906f60f72e00aad2fb000939449ff32e upstream.
Commit
f0fbf0abc093 ("x86: integrate delay functions") converted
delay_tsc() into a random delay generator for 64 bit. The reason is
that it merged the mostly identical versions of delay_32.c and
delay_64.c. Though the subtle difference of the result was:
static void delay_tsc(unsigned long loops)
{
- unsigned bclock, now;
+ unsigned long bclock, now;
Now the function uses rdtscl() which returns the lower 32bit of the
TSC. On 32bit that's not problematic as unsigned long is 32bit. On 64
bit this fails when the lower 32bit are close to wrap around when
bclock is read, because the following check
if ((now - bclock) >= loops)
break;
evaluated to true on 64bit for e.g. bclock = 0xffffffff and now = 0
because the unsigned long (now - bclock) of these values results in
0xffffffff00000001 which is definitely larger than the loops
value. That explains Tvortkos observation:
"Because I am seeing udelay(500) (_occasionally_) being short, and
that by delaying for some duration between 0us (yep) and 491us."
Make those variables explicitely u32 again, so this works for both 32
and 64 bit.
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
David S. Miller [Fri, 12 Nov 2010 21:35:00 +0000 (13:35 -0800)]
tcp: Don't change unlocked socket state in tcp_v4_err().
commit
8f49c2703b33519aaaccc63f571b465b9d2b3a2d upstream.
Alexey Kuznetsov noticed a regression introduced by
commit
f1ecd5d9e7366609d640ff4040304ea197fbc618
("Revert Backoff [v3]: Revert RTO on ICMP destination unreachable")
The RTO and timer modification code added to tcp_v4_err()
doesn't check sock_owned_by_user(), which if true means we
don't have exclusive access to the socket and therefore cannot
modify it's critical state.
Just skip this new code block if sock_owned_by_user() is true
and eliminate the now superfluous sock_owned_by_user() code
block contained within.
Reported-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
CC: Damian Lukowski <damian@tvk.rwth-aachen.de>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
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.
Cc: <stable@vger.kernel.org>
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: Willy Tarreau <w@1wt.eu>
Greg Kroah-Hartman [Fri, 4 May 2012 19:09:39 +0000 (12:09 -0700)]
hfsplus: Fix potential buffer overflows
commit
6f24f892871acc47b40dd594c63606a17c714f77 upstream
Commit
ec81aecb2966 ("hfs: fix a potential buffer overflow") fixed a few
potential buffer overflows in the hfs filesystem. But as Timo Warns
pointed out, these changes also need to be made on the hfsplus
filesystem as well.
Reported-by: Timo Warns <warns@pre-sense.de>
Acked-by: WANG Cong <amwang@redhat.com>
Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Sage Weil <sage@newdream.net>
Cc: Eugene Teo <eteo@redhat.com>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Dave Anderson <anderson@redhat.com>
Cc: stable <stable@vger.kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jeff Mahoney [Wed, 25 Apr 2012 14:32:09 +0000 (14:32 +0000)]
dl2k: Clean up rio_ioctl
commit
1bb57e940e1958e40d51f2078f50c3a96a9b2d75 upstream
The dl2k driver's rio_ioctl call has a few issues:
- No permissions checking
- Implements SIOCGMIIREG and SIOCGMIIREG using the SIOCDEVPRIVATE numbers
- Has a few ioctls that may have been used for debugging at one point
but have no place in the kernel proper.
This patch removes all but the MII ioctls, renumbers them to use the
standard ones, and adds the proper permission check for SIOCSMIIREG.
We can also get rid of the dl2k-specific struct mii_data in favor of
the generic struct mii_ioctl_data.
Since we have the phyid on hand, we can add the SIOCGMIIPHY ioctl too.
Most of the MII code for the driver could probably be converted to use
the generic MII library but I don't have a device to test the results.
Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Francois Romieu [Sun, 21 Aug 2011 16:32:05 +0000 (18:32 +0200)]
dl2k: use standard #defines from mii.h.
commit
78f6a6bd89e9a33e4be1bc61e6990a1172aa396e upstream
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jason Wang [Wed, 30 May 2012 21:18:10 +0000 (21:18 +0000)]
net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()
commit
cc9b17ad29ecaa20bfe426a8d4dbfb94b13ff1cc upstream
We need to validate the number of pages consumed by data_len, otherwise frags
array could be overflowed by userspace. So this patch validate data_len and
return -EMSGSIZE when data_len may occupies more frags than MAX_SKB_FRAGS.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
David Gibson [Wed, 21 Mar 2012 23:34:12 +0000 (16:34 -0700)]
hugepages: fix use after free bug in "quota" handling
commit
90481622d75715bfcb68501280a917dbfe516029 upstream
hugetlbfs_{get,put}_quota() are badly named. They don't interact with the
general quota handling code, and they don't much resemble its behaviour.
Rather than being about maintaining limits on on-disk block usage by
particular users, they are instead about maintaining limits on in-memory
page usage (including anonymous MAP_PRIVATE copied-on-write pages)
associated with a particular hugetlbfs filesystem instance.
Worse, they work by having callbacks to the hugetlbfs filesystem code from
the low-level page handling code, in particular from free_huge_page().
This is a layering violation of itself, but more importantly, if the
kernel does a get_user_pages() on hugepages (which can happen from KVM
amongst others), then the free_huge_page() can be delayed until after the
associated inode has already been freed. If an unmount occurs at the
wrong time, even the hugetlbfs superblock where the "quota" limits are
stored may have been freed.
Andrew Barry proposed a patch to fix this by having hugepages, instead of
storing a pointer to their address_space and reaching the superblock from
there, had the hugepages store pointers directly to the superblock,
bumping the reference count as appropriate to avoid it being freed.
Andrew Morton rejected that version, however, on the grounds that it made
the existing layering violation worse.
This is a reworked version of Andrew's patch, which removes the extra, and
some of the existing, layering violation. It works by introducing the
concept of a hugepage "subpool" at the lower hugepage mm layer - that is a
finite logical pool of hugepages to allocate from. hugetlbfs now creates
a subpool for each filesystem instance with a page limit set, and a
pointer to the subpool gets added to each allocated hugepage, instead of
the address_space pointer used now. The subpool has its own lifetime and
is only freed once all pages in it _and_ all other references to it (i.e.
superblocks) are gone.
subpools are optional - a NULL subpool pointer is taken by the code to
mean that no subpool limits are in effect.
Previous discussion of this bug found in: "Fix refcounting in hugetlbfs
quota handling.". See: https://lkml.org/lkml/2011/8/11/28 or
http://marc.info/?l=linux-mm&m=
126928970510627&w=1
v2: Fixed a bug spotted by Hillf Danton, and removed the extra parameter to
alloc_huge_page() - since it already takes the vma, it is not necessary.
Signed-off-by: Andrew Barry <abarry@cray.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Cc: Hugh Dickins <hughd@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
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>
[dannf: adjusted to apply to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
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: Willy Tarreau <w@1wt.eu>
Jan Kara [Wed, 11 Jan 2012 18:52:10 +0000 (18:52 +0000)]
xfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink()
commit
9b025eb3a89e041bab6698e3858706be2385d692 upstream.
Commit
b52a360b forgot to call xfs_iunlock() when it detected corrupted
symplink and bailed out. Fix it by jumping to 'out' instead of doing return.
CC: stable@kernel.org
CC: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Alex Elder <elder@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Carlos Maiolino [Mon, 7 Nov 2011 16:10:24 +0000 (16:10 +0000)]
xfs: Fix possible memory corruption in xfs_readlink
commit
b52a360b2aa1c59ba9970fb0f52bbb093fcc7a24 upstream
Fixes a possible memory corruption when the link is larger than
MAXPATHLEN and XFS_DEBUG is not enabled. This also remove the
S_ISLNK assert, since the inode mode is checked previously in
xfs_readlink_by_handle() and via VFS.
Updated to address concerns raised by Ben Hutchings about the loose
attention paid to 32- vs 64-bit values, and the lack of handling a
potentially negative pathlen value:
- Changed type of "pathlen" to be xfs_fsize_t, to match that of
ip->i_d.di_size
- Added checking for a negative pathlen to the too-long pathlen
test, and generalized the message that gets reported in that case
to reflect the change
As a result, if a negative pathlen were encountered, this function
would return EFSCORRUPTED (and would fail an assertion for a debug
build)--just as would a too-long pathlen.
Signed-off-by: Alex Elder <aelder@sgi.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Avi Kivity [Wed, 18 Apr 2012 16:23:50 +0000 (19:23 +0300)]
KVM: ia64: fix build due to typo
commit
8281715b4109b5ee26032ff7b77c0d575c4150f7 upstream.
s/kcm/kvm/.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Avi Kivity [Mon, 5 Mar 2012 12:23:29 +0000 (14:23 +0200)]
KVM: Ensure all vcpus are consistent with in-kernel irqchip settings
commit
3e515705a1f46beb1c942bb8043c16f8ac7b1e9e upstream
If some vcpus are created before KVM_CREATE_IRQCHIP, then
irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading
to potential NULL pointer dereferences.
Fix by:
- ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called
- ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP
This is somewhat long winded because vcpu->arch.apic is created without
kvm->lock held.
Based on earlier patch by Michael Ellerman.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Avi Kivity <avi@redhat.com>
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Marcelo Tosatti [Thu, 29 Oct 2009 15:44:15 +0000 (13:44 -0200)]
KVM: x86: disallow multiple KVM_CREATE_IRQCHIP
commit
3ddea128ad75bd33e88780fe44f44c3717369b98 upstream
Otherwise kvm will leak memory on multiple KVM_CREATE_IRQCHIP.
Also serialize multiple accesses with kvm->lock.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Louis Rilling [Fri, 4 Dec 2009 13:52:42 +0000 (14:52 +0100)]
block: Fix io_context leak after failure of clone with CLONE_IO
commit
b69f2292063d2caf37ca9aec7d63ded203701bf3 upstream
With CLONE_IO, parent's io_context->nr_tasks is incremented, but never
decremented whenever copy_process() fails afterwards, which prevents
exit_io_context() from calling IO schedulers exit functions.
Give a task_struct to exit_io_context(), and call exit_io_context() instead of
put_io_context() in copy_process() cleanup path.
Signed-off-by: Louis Rilling <louis.rilling@kerlabs.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Louis Rilling [Fri, 4 Dec 2009 13:52:41 +0000 (14:52 +0100)]
block: Fix io_context leak after clone with CLONE_IO
commit
61cc74fbb87af6aa551a06a370590c9bc07e29d9 upstream
With CLONE_IO, copy_io() increments both ioc->refcount and ioc->nr_tasks.
However exit_io_context() only decrements ioc->refcount if ioc->nr_tasks
reaches 0.
Always call put_io_context() in exit_io_context().
Signed-off-by: Louis Rilling <louis.rilling@kerlabs.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Stephan Bärwolf [Thu, 12 Jan 2012 15:43:04 +0000 (16:43 +0100)]
KVM: x86: fix missing checks in syscall emulation
commit
c2226fc9e87ba3da060e47333657cd6616652b84 upstream
On hosts without this patch, 32bit guests will crash (and 64bit guests
may behave in a wrong way) for example by simply executing following
nasm-demo-application:
[bits 32]
global _start
SECTION .text
_start: syscall
(I tested it with winxp and linux - both always crashed)
Disassembly of section .text:
00000000 <_start>:
0: 0f 05 syscall
The reason seems a missing "invalid opcode"-trap (int6) for the
syscall opcode "0f05", which is not available on Intel CPUs
within non-longmodes, as also on some AMD CPUs within legacy-mode.
(depending on CPU vendor, MSR_EFER and cpuid)
Because previous mentioned OSs may not engage corresponding
syscall target-registers (STAR, LSTAR, CSTAR), they remain
NULL and (non trapping) syscalls are leading to multiple
faults and finally crashs.
Depending on the architecture (AMD or Intel) pretended by
guests, various checks according to vendor's documentation
are implemented to overcome the current issue and behave
like the CPUs physical counterparts.
[mtosatti: cleanup/beautify code]
[bwh: Backport to 2.6.32:
- Add the prerequisite read of EFER
- Return -1 in the error cases rather than invoking emulate_ud()
directly
- Adjust context]
[dannf: fix build by passing x86_emulate_ops through each call]
Signed-off-by: Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Stephan Bärwolf [Thu, 12 Jan 2012 15:43:03 +0000 (16:43 +0100)]
KVM: x86: extend "struct x86_emulate_ops" with "get_cpuid"
commit
bdb42f5afebe208eae90406959383856ae2caf2b upstream
In order to be able to proceed checks on CPU-specific properties
within the emulator, function "get_cpuid" is introduced.
With "get_cpuid" it is possible to virtually call the guests
"cpuid"-opcode without changing the VM's context.
[mtosatti: cleanup/beautify code]
[bwh: Backport to 2.6.32:
- Don't use emul_to_vcpu
- Adjust context]
Signed-off-by: Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Ben Hutchings [Sun, 20 Mar 2011 06:48:05 +0000 (06:48 +0000)]
rose: Add length checks to CALL_REQUEST parsing
commit
e0bccd315db0c2f919e7fcf9cb60db21d9986f52 upstream
Define some constant offsets for CALL_REQUEST based on the description
at <http://www.techfest.com/networking/wan/x25plp.htm> and the
definition of ROSE as using 10-digit (5-byte) addresses. Use them
consistently. Validate all implicit and explicit facilities lengths.
Validate the address length byte rather than either trusting or
assuming its value.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jan Kiszka [Wed, 14 Dec 2011 18:25:13 +0000 (19:25 +0100)]
KVM: x86: Prevent starting PIT timers in the absence of irqchip support
commit
0924ab2cfa98b1ece26c033d696651fd62896c69 upstream
User space may create the PIT and forgets about setting up the irqchips.
In that case, firing PIT IRQs will crash the host:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000128
IP: [<
ffffffffa10f6280>] kvm_set_irq+0x30/0x170 [kvm]
...
Call Trace:
[<
ffffffffa11228c1>] pit_do_work+0x51/0xd0 [kvm]
[<
ffffffff81071431>] process_one_work+0x111/0x4d0
[<
ffffffff81071bb2>] worker_thread+0x152/0x340
[<
ffffffff81075c8e>] kthread+0x7e/0x90
[<
ffffffff815a4474>] kernel_thread_helper+0x4/0x10
Prevent this by checking the irqchip mode before starting a timer. We
can't deny creating the PIT if the irqchips aren't set up yet as
current user land expects this order to work.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Alex Williamson [Wed, 21 Dec 2011 04:59:09 +0000 (21:59 -0700)]
KVM: Device assignment permission checks
commit
3d27e23b17010c668db311140b17bbbb70c78fb9 upstream
Only allow KVM device assignment to attach to devices which:
- Are not bridges
- Have BAR resources (assume others are special devices)
- The user has permissions to use
Assigning a bridge is a configuration error, it's not supported, and
typically doesn't result in the behavior the user is expecting anyway.
Devices without BAR resources are typically chipset components that
also don't have host drivers. We don't want users to hold such devices
captive or cause system problems by fencing them off into an iommu
domain. We determine "permission to use" by testing whether the user
has access to the PCI sysfs resource files. By default a normal user
will not have access to these files, so it provides a good indication
that an administration agent has granted the user access to the device.
[Yang Bai: add missing #include]
[avi: fix comment style]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Yang Bai <hamo.by@gmail.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Alex Williamson [Wed, 21 Dec 2011 04:59:03 +0000 (21:59 -0700)]
KVM: Remove ability to assign a device without iommu support
commit
423873736b78f549fbfa2f715f2e4de7e6c5e1e9 upstream
This option has no users and it exposes a security hole that we
can allow devices to be assigned without iommu protection. Make
KVM_DEV_ASSIGN_ENABLE_IOMMU a mandatory option.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Willy Tarreau [Sun, 30 Sep 2012 16:22:21 +0000 (18:22 +0200)]
PNP: fix "work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB"
Initial stable commit :
2215d91091c465fd58da7814d1c10e09ac2d8307
This patch backported into 2.6.32.55 is enabled when CONFIG_AMD_NB is set,
but this config option does not exist in 2.6.32, it was called CONFIG_K8_NB,
so the fix was never applied. Some other changes were needed to make it work.
first, the correct include file name was asm/k8.h and not asm/amd_nb.h, and
second, amd_get_mmconfig_range() is needed and was merged by previous patch.
Thanks to Jiri Slabi who reported the issue and diagnosed all the dependencies.
Signed-off-by: Willy Tarreau <w@1wt.eu>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Bjorn Helgaas [Thu, 5 Jan 2012 21:27:19 +0000 (14:27 -0700)]
x86/PCI: amd: factor out MMCONFIG discovery
commit
24d25dbfa63c376323096660bfa9ad45a08870ce upstream.
This factors out the AMD native MMCONFIG discovery so we can use it
outside amd_bus.c.
amd_bus.c reads AMD MSRs so it can remove the MMCONFIG area from the
PCI resources. We may also need the MMCONFIG information to work
around BIOS defects in the ACPI MCFG table.
Cc: Borislav Petkov <borislav.petkov@amd.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: stable@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[WT: this patch was initially not planned for 2.6.32 but is required by commit
2215d910 merged into 2.6.32.55 and which relies on amd_get_mmconfig_range() ]
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Mike Galbraith [Wed, 5 Jan 2011 04:41:17 +0000 (05:41 +0100)]
sched: Fix signed unsigned comparison in check_preempt_tick()
commit
d7d8294415f0ce4254827d4a2a5ee88b00be52a8 upstream.
Signed unsigned comparison may lead to superfluous resched if leftmost
is right of the current task, wasting a few cycles, and inadvertently
_lengthening_ the current task's slice.
Reported-by: Venkatesh Pallipadi <venki@google.com>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <
1294202477.9384.5.camel@marge.simson.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Willy Tarreau <w@1wt.eu>
tom.leiming@gmail.com [Thu, 22 Mar 2012 03:22:38 +0000 (03:22 +0000)]
usbnet: don't clear urb->dev in tx_complete
commit
5d5440a835710d09f0ef18da5000541ec98b537a upstream.
URB unlinking is always racing with its completion and tx_complete
may be called before or during running usb_unlink_urb, so tx_complete
must not clear urb->dev since it will be used in unlink path,
otherwise invalid memory accesses or usb device leak may be caused
inside usb_unlink_urb.
Cc: stable@kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
tom.leiming@gmail.com [Thu, 22 Mar 2012 03:22:18 +0000 (03:22 +0000)]
usbnet: increase URB reference count before usb_unlink_urb
commit
0956a8c20b23d429e79ff86d4325583fc06f9eb4 upstream.
Commit
4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid
recursive locking in usbnet_stop()) fixes the recursive locking
problem by releasing the skb queue lock, but it makes usb_unlink_urb
racing with defer_bh, and the URB to being unlinked may be freed before
or during calling usb_unlink_urb, so use-after-free problem may be
triggerd inside usb_unlink_urb.
The patch fixes the use-after-free problem by increasing URB
reference count with skb queue lock held before calling
usb_unlink_urb, so the URB won't be freed until return from
usb_unlink_urb.
Cc: stable@kernel.org
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oliver@neukum.org>
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jiri Bohac [Tue, 19 Apr 2011 02:09:55 +0000 (02:09 +0000)]
bonding: 802.3ad - fix agg_device_up
commit
2430af8b7fa37ac0be102c77f9dc6ee669d24ba9 upstream.
The slave member of struct aggregator does not necessarily point
to a slave which is part of the aggregator. It points to the
slave structure containing the aggregator structure, while
completely different slaves (or no slaves at all) may be part of
the aggregator.
The agg_device_up() function wrongly uses agg->slave to find the state
of the aggregator. Use agg->lag_ports->slave instead. The bug has
been introduced by commit
4cd6fe1c6483cde93e2ec91f58b7af9c9eea51ad
("bonding: fix link down handling in 802.3ad mode").
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Xiaotian Feng [Thu, 3 Mar 2011 10:08:24 +0000 (18:08 +0800)]
tty_audit: fix tty_audit_add_data live lock on audit disabled
commit
00bff392c81e4fb1901e5160fdd5afdb2546a6ab upstream.
The current tty_audit_add_data code:
do {
size_t run;
run = N_TTY_BUF_SIZE - buf->valid;
if (run > size)
run = size;
memcpy(buf->data + buf->valid, data, run);
buf->valid += run;
data += run;
size -= run;
if (buf->valid == N_TTY_BUF_SIZE)
tty_audit_buf_push_current(buf);
} while (size != 0);
If the current buffer is full, kernel will then call tty_audit_buf_push_current
to empty the buffer. But if we disabled audit at the same time, tty_audit_buf_push()
returns immediately if audit_enabled is zero. Without emptying the buffer.
With obvious effect on tty_audit_add_data() that ends up spinning in that loop,
copying 0 bytes at each iteration and attempting to push each time without any effect.
Holding the lock all along.
Suggested-by: Alexander Viro <aviro@redhat.com>
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Junxiao Bi [Wed, 22 Aug 2012 02:21:07 +0000 (10:21 +0800)]
oprofile: use KM_NMI slot for kmap_atomic
If one kernel path is using KM_USER0 slot and is interrupted by
the oprofile nmi, then in copy_from_user_nmi(), the KM_USER0 slot
will be overwrite and cleared to zero at last, when the control
return to the original kernel path, it will access an invalid
virtual address and trigger a crash.
Cc: Robert Richter <robert.richter@amd.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
[WT: According to Junxiao and Robert, this patch is needed for stable kernels
which include a backport of
a0e3e70243f5b270bc3eca718f0a9fa5e6b8262e without
3e4d3af501cccdc8a8cca41bdbe57d54ad7e7e73, but there is no exact equivalent in
mainline]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Colin Ian King [Thu, 5 Apr 2012 19:31:58 +0000 (13:31 -0600)]
eCryptfs: Clear ECRYPTFS_NEW_FILE flag during truncate
BugLink: http://bugs.launchpad.net/bugs/745836
The ECRYPTFS_NEW_FILE crypt_stat flag is set upon creation of a new
eCryptfs file. When the flag is set, eCryptfs reads directly from the
lower filesystem when bringing a page up to date. This means that no
offset translation (for the eCryptfs file metadata in the lower file)
and no decryption is performed. The flag is cleared just before the
first write is completed (at the beginning of ecryptfs_write_begin()).
It was discovered that if a new file was created and then extended with
truncate, the ECRYPTFS_NEW_FILE flag was not cleared. If pages
corresponding to this file are ever reclaimed, any subsequent reads
would result in userspace seeing eCryptfs file metadata and encrypted
file contents instead of the expected decrypted file contents.
Data corruption is possible if the file is written to before the
eCryptfs directory is unmounted. The data written will be copied into
pages which have been read directly from the lower file rather than
zeroed pages, as would be expected after extending the file with
truncate.
This flag, and the functionality that used it, was removed in upstream
kernels in 2.6.39 with the following commits:
bd4f0fe8bb7c73c738e1e11bc90d6e2cf9c6e20e
fed8859b3ab94274c986cbdf7d27130e0545f02c
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Colin Ian King [Thu, 5 Apr 2012 19:31:56 +0000 (13:31 -0600)]
eCryptfs: Copy up lower inode attrs after setting lower xattr
commit
545d680938be1e86a6c5250701ce9abaf360c495 upstream.
After passing through a ->setxattr() call, eCryptfs needs to copy the
inode attributes from the lower inode to the eCryptfs inode, as they
may have changed in the lower filesystem's ->setxattr() path.
One example is if an extended attribute containing a POSIX Access
Control List is being set. The new ACL may cause the lower filesystem to
modify the mode of the lower inode and the eCryptfs inode would need to
be updated to reflect the new mode.
https://launchpad.net/bugs/926292
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Sebastien Bacher <seb128@ubuntu.com>
Cc: John Johansen <john.johansen@canonical.com>
Cc: <stable@vger.kernel.org>
Acked-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Stuart Hayes [Sun, 22 Jul 2012 19:27:23 +0000 (20:27 +0100)]
usb: Fix deadlock in hid_reset when Dell iDRAC is reset
This was fixed upstream by commit
e22bee782b3b00bd4534ae9b1c5fb2e8e6573c5c
('workqueue: implement concurrency managed dynamic worker pool'), but
that is far too large a change for stable.
When Dell iDRAC is reset, the iDRAC's USB keyboard/mouse device stops
responding but is not actually disconnected. This causes usbhid to
hid hid_io_error(), and you get a chain of calls like...
hid_reset()
usb_reset_device()
usb_reset_and_verify_device()
usb_ep0_reinit()
usb_disble_endpoint()
usb_hcd_disable_endpoint()
ehci_endpoint_disable()
Along the way, as a result of an error/timeout with a USB transaction,
ehci_clear_tt_buffer() calls usb_hub_clear_tt_buffer() (to clear a failed
transaction out of the transaction translator in the hub), which schedules
hub_tt_work() to be run (using keventd), and then sets qh->clearing_tt=1 so
that nobody will mess with that qh until the TT is cleared.
But run_workqueue() never happens for the keventd workqueue on that CPU, so
hub_tt_work() never gets run. And qh->clearing_tt never gets changed back to
0.
This causes ehci_endpoint_disable() to get stuck in a loop waiting for
qh->clearing_tt to go to 0.
Part of the problem is hid_reset() is itself running on keventd. So
when that thread gets a timeout trying to talk to the HID device, it
schedules clear_work (to run hub_tt_work) to run, and then gets stuck
in ehci_endpoint_disable waiting for it to run.
However, clear_work never gets run because the workqueue for that CPU
is still waiting for hid_reset to finish.
A much less invasive patch for earlier kernels is to just schedule
clear_work on khubd if the usb code needs to clear the TT and it sees
that it is already running on keventd. Khubd isn't used by default
because it can get blocked by device enumeration sometimes, but I
think it should be ok for a backup for unusual cases like this just to
prevent deadlock.
Signed-off-by: Stuart Hayes <stuart_hayes@dell.com>
Signed-off-by: Shyam Iyer <shyam_iyer@dell.com>
[bwh: Use current_is_keventd() rather than checking current->{flags,comm}]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Adam Jackson [Fri, 16 Apr 2010 22:20:57 +0000 (18:20 -0400)]
drm/i915: Attempt to fix watermark setup on 85x (v2)
commit
8f4695ed1c9e068772bcce4cd4ff03f88d57a008 upstream.
IS_MOBILE() catches 85x, so we'd always try to use the 9xx FIFO sizing;
since there's an explicit 85x version, this seems wrong.
v2: Handle 830m correctly too.
[jn: backport to 2.6.32.y to address
https://bugzilla.kernel.org/show_bug.cgi?id=42839]
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Dan Williams [Wed, 3 Mar 2010 18:47:43 +0000 (11:47 -0700)]
ioat2: kill pending flag
commit
281befa5592b0c5f9a3856b5666c62ac66d3d9ee upstream.
The pending == 2 case no longer exists in the driver so, we can use
ioat2_ring_pending() outside the lock to determine if there might be any
descriptors in the ring that the hardware has not seen.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Backported-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
John Stultz [Tue, 18 Sep 2012 02:32:10 +0000 (22:32 -0400)]
time: Move ktime_t overflow checking into timespec_valid_strict
This is a -stable backport of
cee58483cf56e0ba355fdd97ff5e8925329aa936
Andreas Bombe reported that the added ktime_t overflow checking added to
timespec_valid in commit
4e8b14526ca7 ("time: Improve sanity checking of
timekeeping inputs") was causing problems with X.org because it caused
timeouts larger then KTIME_T to be invalid.
Previously, these large timeouts would be clamped to KTIME_MAX and would
never expire, which is valid.
This patch splits the ktime_t overflow checking into a new
timespec_valid_strict function, and converts the timekeeping codes
internal checking to use this more strict function.
Reported-and-tested-by: Andreas Bombe <aeb@debian.org>
Cc: Zhouping Liu <zliu@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
John Stultz [Tue, 18 Sep 2012 02:32:09 +0000 (22:32 -0400)]
time: Avoid making adjustments if we haven't accumulated anything
This is a -stable backport of
bf2ac312195155511a0f79325515cbb61929898a
If update_wall_time() is called and the current offset isn't large
enough to accumulate, avoid re-calling timekeeping_adjust which may
change the clock freq and can cause 1ns inconsistencies with
CLOCK_REALTIME_COARSE/CLOCK_MONOTONIC_COARSE.
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1345595449-34965-5-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
John Stultz [Tue, 18 Sep 2012 02:32:08 +0000 (22:32 -0400)]
time: Improve sanity checking of timekeeping inputs
This is a -stable backport of
4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b
Unexpected behavior could occur if the time is set to a value large
enough to overflow a 64bit ktime_t (which is something larger then the
year 2262).
Also unexpected behavior could occur if large negative offsets are
injected via adjtimex.
So this patch improves the sanity check timekeeping inputs by
improving the timespec_valid() check, and then makes better use of
timespec_valid() to make sure we don't set the time to an invalid
negative value or one that overflows ktime_t.
Note: This does not protect from setting the time close to overflowing
ktime_t and then letting natural accumulation cause the overflow.
Reported-by: CAI Qian <caiqian@redhat.com>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Zhouping Liu <zliu@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1344454580-17031-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Thomas Gleixner [Tue, 17 Jul 2012 22:05:35 +0000 (18:05 -0400)]
timekeeping: Add missing update call in timekeeping_resume()
This is a backport of
3e997130bd2e8c6f5aaa49d6e3161d4d29b43ab0
The leap second rework unearthed another issue of inconsistent data.
On timekeeping_resume() the timekeeper data is updated, but nothing
calls timekeeping_update(), so now the update code in the timer
interrupt sees stale values.
This has been the case before those changes, but then the timer
interrupt was using stale data as well so this went unnoticed for quite
some time.
Add the missing update call, so all the data is consistent everywhere.
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Reported-and-tested-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Reported-and-tested-by: Martin Steigerwald <Martin@lichtvoll.de>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: Linux PM list <linux-pm@vger.kernel.org>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
John Stultz [Tue, 17 Jul 2012 22:05:34 +0000 (18:05 -0400)]
hrtimer: Update hrtimer base offsets each hrtimer_interrupt
This is a backport of
5baefd6d84163443215f4a99f6a20f054ef11236
The update of the hrtimer base offsets on all cpus cannot be made
atomically from the timekeeper.lock held and interrupt disabled region
as smp function calls are not allowed there.
clock_was_set(), which enforces the update on all cpus, is called
either from preemptible process context in case of do_settimeofday()
or from the softirq context when the offset modification happened in
the timer interrupt itself due to a leap second.
In both cases there is a race window for an hrtimer interrupt between
dropping timekeeper lock, enabling interrupts and clock_was_set()
issuing the updates. Any interrupt which arrives in that window will
see the new time but operate on stale offsets.
So we need to make sure that an hrtimer interrupt always sees a
consistent state of time and offsets.
ktime_get_update_offsets() allows us to get the current monotonic time
and update the per cpu hrtimer base offsets from hrtimer_interrupt()
to capture a consistent state of monotonic time and the offsets. The
function replaces the existing ktime_get() calls in hrtimer_interrupt().
The overhead of the new function vs. ktime_get() is minimal as it just
adds two store operations.
This ensures that any changes to realtime or boottime offsets are
noticed and stored into the per-cpu hrtimer base structures, prior to
any hrtimer expiration and guarantees that timers are not expired early.
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1341960205-56738-8-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Thomas Gleixner [Tue, 17 Jul 2012 22:05:33 +0000 (18:05 -0400)]
timekeeping: Provide hrtimer update function
This is a backport of
f6c06abfb3972ad4914cef57d8348fcb2932bc3b
To finally fix the infamous leap second issue and other race windows
caused by functions which change the offsets between the various time
bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a
function which atomically gets the current monotonic time and updates
the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic
overhead. The previous patch which provides ktime_t offsets allows us
to make this function almost as cheap as ktime_get() which is going to
be replaced in hrtimer_interrupt().
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Link: http://lkml.kernel.org/r/1341960205-56738-7-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Thomas Gleixner [Tue, 17 Jul 2012 22:05:32 +0000 (18:05 -0400)]
hrtimers: Move lock held region in hrtimer_interrupt()
This is a backport of
196951e91262fccda81147d2bcf7fdab08668b40
We need to update the base offsets from this code and we need to do
that under base->lock. Move the lock held region around the
ktime_get() calls. The ktime_get() calls are going to be replaced with
a function which gets the time and the offsets atomically.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Link: http://lkml.kernel.org/r/1341960205-56738-6-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Thomas Gleixner [Tue, 17 Jul 2012 22:05:31 +0000 (18:05 -0400)]
timekeeping: Maintain ktime_t based offsets for hrtimers
This is a backport of
5b9fe759a678e05be4937ddf03d50e950207c1c0
We need to update the hrtimer clock offsets from the hrtimer interrupt
context. To avoid conversions from timespec to ktime_t maintain a
ktime_t based representation of those offsets in the timekeeper. This
puts the conversion overhead into the code which updates the
underlying offsets and provides fast accessible values in the hrtimer
interrupt.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1341960205-56738-4-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
John Stultz [Tue, 17 Jul 2012 22:05:30 +0000 (18:05 -0400)]
timekeeping: Fix leapsecond triggered load spike issue
This is a backport of
4873fa070ae84a4115f0b3c9dfabc224f1bc7c51
The timekeeping code misses an update of the hrtimer subsystem after a
leap second happened. Due to that timers based on CLOCK_REALTIME are
either expiring a second early or late depending on whether a leap
second has been inserted or deleted until an operation is initiated
which causes that update. Unless the update happens by some other
means this discrepancy between the timekeeping and the hrtimer data
stays forever and timers are expired either early or late.
The reported immediate workaround - $ data -s "`date`" - is causing a
call to clock_was_set() which updates the hrtimer data structures.
See: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix
Add the missing clock_was_set() call to update_wall_time() in case of
a leap second event. The actual update is deferred to softirq context
as the necessary smp function call cannot be invoked from hard
interrupt context.
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Reported-by: Jan Engelhardt <jengelh@inai.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1341960205-56738-3-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
John Stultz [Tue, 17 Jul 2012 22:05:29 +0000 (18:05 -0400)]
hrtimer: Provide clock_was_set_delayed()
This is a backport of
f55a6faa384304c89cfef162768e88374d3312cb
clock_was_set() cannot be called from hard interrupt context because
it calls on_each_cpu().
For fixing the widely reported leap seconds issue it is necessary to
call it from hard interrupt context, i.e. the timer tick code, which
does the timekeeping updates.
Provide a new function which denotes it in the hrtimer cpu base
structure of the cpu on which it is called and raise the hrtimer
softirq. We then execute the clock_was_set() notificiation from
softirq context in run_hrtimer_softirq(). The hrtimer softirq is
rarely used, so polling the flag there is not a performance issue.
[ tglx: Made it depend on CONFIG_HIGH_RES_TIMERS. We really should get
rid of all this ifdeffery ASAP ]
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Reported-by: Jan Engelhardt <jengelh@inai.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1341960205-56738-2-git-send-email-johnstul@us.ibm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Thomas Gleixner [Tue, 17 Jul 2012 22:05:28 +0000 (18:05 -0400)]
time: Move common updates to a function
This is a backport of
cc06268c6a87db156af2daed6e96a936b955cc82
While not a bugfix itself, it allows following fixes to backport
in a more straightforward manner.
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Eric Dumazet <eric.dumazet@gmail.com>
CC: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
John Stultz [Tue, 17 Jul 2012 22:05:27 +0000 (18:05 -0400)]
timekeeping: Fix CLOCK_MONOTONIC inconsistency during leapsecond
This is a backport of
fad0c66c4bb836d57a5f125ecd38bed653ca863a
which resolves a bug the previous commit.
Commit
6b43ae8a61 (ntp: Fix leap-second hrtimer livelock) broke the
leapsecond update of CLOCK_MONOTONIC. The missing leapsecond update to
wall_to_monotonic causes discontinuities in CLOCK_MONOTONIC.
Adjust wall_to_monotonic when NTP inserted a leapsecond.
Reported-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Richard Cochran <richardcochran@gmail.com>
Link: http://lkml.kernel.org/r/1338400497-12420-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Richard Cochran [Tue, 17 Jul 2012 22:05:26 +0000 (18:05 -0400)]
ntp: Correct TAI offset during leap second
This is a backport of
dd48d708ff3e917f6d6b6c2b696c3f18c019feed
When repeating a UTC time value during a leap second (when the UTC
time should be 23:59:60), the TAI timescale should not stop. The kernel
NTP code increments the TAI offset one second too late. This patch fixes
the issue by incrementing the offset during the leap second itself.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
John Stultz [Tue, 17 Jul 2012 22:05:25 +0000 (18:05 -0400)]
ntp: Fix leap-second hrtimer livelock
This is a backport of
6b43ae8a619d17c4935c3320d2ef9e92bdeed05d
This should have been backported when it was commited, but I
mistook the problem as requiring the ntp_lock changes
that landed in 3.4 in order for it to occur.
Unfortunately the same issue can happen (with only one cpu)
as follows:
do_adjtimex()
write_seqlock_irq(&xtime_lock);
process_adjtimex_modes()
process_adj_status()
ntp_start_leap_timer()
hrtimer_start()
hrtimer_reprogram()
tick_program_event()
clockevents_program_event()
ktime_get()
seq = req_seqbegin(xtime_lock); [DEADLOCK]
This deadlock will no always occur, as it requires the
leap_timer to force a hrtimer_reprogram which only happens
if its set and there's no sooner timer to expire.
NOTE: This patch, being faithful to the original commit,
introduces a bug (we don't update wall_to_monotonic),
which will be resovled by backporting a following fix.
Original commit message below:
Since commit
7dffa3c673fbcf835cd7be80bb4aec8ad3f51168 the ntp
subsystem has used an hrtimer for triggering the leapsecond
adjustment. However, this can cause a potential livelock.
Thomas diagnosed this as the following pattern:
CPU 0 CPU 1
do_adjtimex()
spin_lock_irq(&ntp_lock);
process_adjtimex_modes(); timer_interrupt()
process_adj_status(); do_timer()
ntp_start_leap_timer(); write_lock(&xtime_lock);
hrtimer_start(); update_wall_time();
hrtimer_reprogram(); ntp_tick_length()
tick_program_event() spin_lock(&ntp_lock);
clockevents_program_event()
ktime_get()
seq = req_seqbegin(xtime_lock);
This patch tries to avoid the problem by reverting back to not using
an hrtimer to inject leapseconds, and instead we handle the leapsecond
processing in the second_overflow() function.
The downside to this change is that on systems that support highres
timers, the leap second processing will occur on a HZ tick boundary,
(ie: ~1-10ms, depending on HZ) after the leap second instead of
possibly sooner (~34us in my tests w/ x86_64 lapic).
This patch applies on top of tip/timers/core.
CC: Sasha Levin <levinsasha928@gmail.com>
CC: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Diagnoised-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Hugh Dickins [Sat, 31 Dec 2011 19:44:01 +0000 (11:44 -0800)]
futex: Fix uninterruptible loop due to gate_area
commit
e6780f7243eddb133cc20ec37fa69317c218b709 upstream.
It was found (by Sasha) that if you use a futex located in the gate
area we get stuck in an uninterruptible infinite loop, much like the
ZERO_PAGE issue.
While looking at this problem, PeterZ realized you'll get into similar
trouble when hitting any install_special_pages() mapping. And are there
still drivers setting up their own special mmaps without page->mapping,
and without special VM or pte flags to make get_user_pages fail?
In most cases, if page->mapping is NULL, we do not need to retry at all:
Linus points out that even /proc/sys/vm/drop_caches poses no problem,
because it ends up using remove_mapping(), which takes care not to
interfere when the page reference count is raised.
But there is still one case which does need a retry: if memory pressure
called shmem_writepage in between get_user_pages_fast dropping page
table lock and our acquiring page lock, then the page gets switched from
filecache to swapcache (and ->mapping set to NULL) whatever the refcount.
Fault it back in to get the page->mapping needed for key->shared.inode.
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PG: 2.6.34 variable is page, not page_head, since it doesn't have
a5b338f2]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Philipp Hahn [Mon, 23 Apr 2012 09:07:53 +0000 (11:07 +0200)]
fix pgd_lock deadlock
commit
a79e53d85683c6dd9f99c90511028adc2043031f upstream.
On Wednesday 16 February 2011 15:49:47 Andrea Arcangeli wrote:
> Subject: fix pgd_lock deadlock
>
> From: Andrea Arcangeli <aarcange@redhat.com>
>
> It's forbidden to take the page_table_lock with the irq disabled or if
> there's contention the IPIs (for tlb flushes) sent with the page_table_lock
> held will never run leading to a deadlock.
>
> Apparently nobody takes the pgd_lock from irq so the _irqsave can be
> removed.
>
> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
This patch (original commit Id for 2.6.38
a79e53d85683c6dd9f99c90511028adc2043031f)
needs to be back-ported to 2.6.32.x as well.
I observed a dead-lock problem when running a PAE enabled Debian 2.6.32.46+
kernel with 6 VCPUs as a KVM on (2.6.32, 3.2, 3.3) kernel, which showed the
following behaviour:
1 VCPU is stuck in
pgd_alloc() =E2=86=92 pgd_prepopulate_pmb() =E2=86=92... =E2=86=92 flush_tlb_others_ipi()
while (!cpumask_empty(to_cpumask(f->flush_cpumask)))
cpu_relax();
(gdb) print f->flush_cpumask
$5 = {1}
while all other VCPUs are stuck in
pgd_alloc() =E2=86=92 spin_lock_irqsave(pgd_lock)
I tracked it down to the commit
2.6.39-rc1:
4981d01eada5354d81c8929d5b2836829ba3df7b
2.6.32.34:
ba456fd7ec1bdc31a4ad4a6bd02802dcaa730a33
x86: Flush TLB if PGD entry is changed in i386 PAE mode
which when reverted made the bug disappear.
Comparing 3.2 to 2.6.32.34 showed that the 'pgd-deadlock'-patch went into
2.6.38, that is before the 'PAE correctness'-patch, so the problem was
probably never observed in the main development branch.
But for 2.6.32 the 'pgd-deadlock' patch is still missing, so the 'PAE
corretness'-patch made the problem worse with 2.6.32.
The Patch was also back-ported to the OpenSUSE Kernel
<http://kernel.opensuse.org/cgit/kernel-source/commit/?id=
ac27c01aa880c65d17043ab87249c613ac4c3635>,
Since the patch didn't apply cleanly on the current Debian kernel, I had to
backport it for us and Debian. The patch is also available from our (German)
Bugzilla <https://forge.univention.org/bugzilla/show_bug.cgi?id=26661> or
from the Debian BTS at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669335>.
I have no easy test case, but running multiple parallel builds inside the VM
normally triggers the bug within seconds to minutes. With the patch applied
the VM survived a night building packages without any problem.
Signed-off-by: Philipp Hahn <hahn@univention.de>
Sincerely
Philipp
-
Philipp Hahn Open Source Software Engineer hahn@univention.de
Univention GmbH be open. fon: +49 421 22 232- 0
Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99
http://www.univention.de/
It's forbidden to take the page_table_lock with the irq disabled
or if there's contention the IPIs (for tlb flushes) sent with
the page_table_lock held will never run leading to a deadlock.
Nobody takes the pgd_lock from irq context so the _irqsave can be
removed.
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: Rik van Riel <riel@redhat.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@kernel.org>
LKML-Reference: <
201102162345.p1GNjMjm021738@imap1.linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Git-commit:
a79e53d85683c6dd9f99c90511028adc2043031f
Signed-off-by: Willy Tarreau <w@1wt.eu>
Eric Sandeen [Mon, 20 Feb 2012 22:53:01 +0000 (17:53 -0500)]
jbd2: clear BH_Delay & BH_Unwritten in journal_unmap_buffer
commit
15291164b22a357cb211b618adfef4fa82fc0de3 upstream.
journal_unmap_buffer()'s zap_buffer: code clears a lot of buffer head
state ala discard_buffer(), but does not touch _Delay or _Unwritten as
discard_buffer() does.
This can be problematic in some areas of the ext4 code which assume
that if they have found a buffer marked unwritten or delay, then it's
a live one. Perhaps those spots should check whether it is mapped
as well, but if jbd2 is going to tear down a buffer, let's really
tear it down completely.
Without this I get some fsx failures on sub-page-block filesystems
up until v3.2, at which point
4e96b2dbbf1d7e81f22047a50f862555a6cb87cb
and
189e868fa8fdca702eb9db9d8afc46b5cb9144c9 make the failures go
away, because buried within that large change is some more flag
clearing. I still think it's worth doing in jbd2, since
->invalidatepage leads here directly, and it's the right place
to clear away these flags.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
BugLink: http://bugs.launchpad.net/bugs/929781
CVE-2011-4086
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Bing Zhao [Thu, 29 Mar 2012 03:19:57 +0000 (20:19 -0700)]
Bluetooth: btusb: fix bInterval for high/super speed isochronous endpoints
commit
fa0fb93f2ac308a76fa64eb57c18511dadf97089 upstream
For high-speed/super-speed isochronous endpoints, the bInterval
value is used as exponent, 2^(bInterval-1). Luckily we have
usb_fill_int_urb() function that handles it correctly. So we just
call this function to fill in the RX URB.
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Benjamin Herrenschmidt [Wed, 21 Mar 2012 01:27:40 +0000 (09:27 +0800)]
powerpc/pmac: Fix SMP kernels on pre-core99 UP machines
commit
78c5c68a4cf4329d17abfa469345ddf323d4fd62 upstream.
The code for "powersurge" SMP would kick in and cause a crash
at boot due to the lack of a NULL test.
Adam Conrad reports that the 3.2 kernel, with CONFIG_SMP=y, will not
boot on an OldWorld G3; we're unconditionally writing to psurge_start,
but this is only set on powersurge machines.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
Reported-by: Adam Conrad <adconrad@ubuntu.com>
Tested-by: Adam Conrad <adconrad@ubuntu.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
David Miller [Fri, 16 Mar 2012 03:14:29 +0000 (20:14 -0700)]
Fix sparc build with newer tools.
commit
e0adb9902fb338a9fe634c3c2a3e474075c733ba upstream.
Newer version of binutils are more strict about specifying the
correct options to enable certain classes of instructions.
The sparc32 build is done for v7 in order to support sun4c systems
which lack hardware integer multiply and divide instructions.
So we have to pass -Av8 when building the assembler routines that
use these instructions and get patched into the kernel when we find
out that we have a v8 capable cpu.
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Sony Chacko [Tue, 15 Mar 2011 21:54:55 +0000 (14:54 -0700)]
netxen: support for GbE port settings
commit
bfd823bd74333615783d8108889814c6d82f2ab0 upstream.
o Enable setting speed and auto negotiation parameters for GbE ports.
o Hardware do not support half duplex setting currently.
David Miller:
Amit please update your patch to silently reject link setting
attempts that are unsupported by the device.
[jn: backported for 2.6.32.y by Ana Guerrero]
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tested-by: Ana Guerrero <ana@debian.org> # HP NC375i
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Acked-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Willy Tarreau [Sat, 17 Mar 2012 10:14:46 +0000 (11:14 +0100)]
Linux 2.6.32.59
Signed-off-by: Willy Tarreau <w@1wt.eu>
David Vrabel [Wed, 14 Mar 2012 11:48:52 +0000 (11:48 +0000)]
blkfront: Fix backtrace in del_gendisk
Commit
89de1669ace055b56f1de1c9f5aca26dd7f17f25 upstream.
The call to del_gendisk follows an non-refcounted gd->queue
pointer. We release the last ref in blk_cleanup_queue. Fixed by
reordering releases accordingly.
Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Maxim Uvarov [Mon, 16 Jan 2012 04:02:50 +0000 (20:02 -0800)]
watchdog: hpwdt: clean up set_memory_x call for 32 bit
commit
97d2a10d5804d585ab0b58efbd710948401b886a upstream.
1. address has to be page aligned.
2. set_memory_x uses page size argument, not size.
Bug causes with following commit:
commit
da28179b4e90dda56912ee825c7eaa62fc103797
Author: Mingarelli, Thomas <Thomas.Mingarelli@hp.com>
Date: Mon Nov 7 10:59:00 2011 +0100
watchdog: hpwdt: Changes to handle NX secure bit in 32bit path
commit
e67d668e147c3b4fec638c9e0ace04319f5ceccd upstream.
This patch makes use of the set_memory_x() kernel API in order
to make necessary BIOS calls to source NMIs.
Signed-off-by: Maxim Uvarov <maxim.uvarov@oracle.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
H. Peter Anvin [Fri, 2 Mar 2012 18:43:49 +0000 (10:43 -0800)]
regset: Return -EFAULT, not -EIO, on host-side memory fault
commit
5189fa19a4b2b4c3bec37c3a019d446148827717 upstream.
There is only one error code to return for a bad user-space buffer
pointer passed to a system call in the same address space as the
system call is executed, and that is EFAULT. Furthermore, the
low-level access routines, which catch most of the faults, return
EFAULT already.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Roland McGrath <roland@hack.frob.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
H. Peter Anvin [Fri, 2 Mar 2012 18:43:48 +0000 (10:43 -0800)]
regset: Prevent null pointer reference on readonly regsets
commit
c8e252586f8d5de906385d8cf6385fee289a825e upstream.
The regset common infrastructure assumed that regsets would always
have .get and .set methods, but not necessarily .active methods.
Unfortunately people have since written regsets without .set methods.
Rather than putting in stub functions everywhere, handle regsets with
null .get or .set methods explicitly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Roland McGrath <roland@hack.frob.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Sebastian Siewior [Wed, 7 Mar 2012 10:19:28 +0000 (10:19 +0000)]
net/usbnet: avoid recursive locking in usbnet_stop()
commit
4231d47e6fe69f061f96c98c30eaf9fb4c14b96d upstream.
|kernel BUG at kernel/rtmutex.c:724!
|[<
c029599c>] (rt_spin_lock_slowlock+0x108/0x2bc) from [<
c01c2330>] (defer_bh+0x1c/0xb4)
|[<
c01c2330>] (defer_bh+0x1c/0xb4) from [<
c01c3afc>] (rx_complete+0x14c/0x194)
|[<
c01c3afc>] (rx_complete+0x14c/0x194) from [<
c01cac88>] (usb_hcd_giveback_urb+0xa0/0xf0)
|[<
c01cac88>] (usb_hcd_giveback_urb+0xa0/0xf0) from [<
c01e1ff4>] (musb_giveback+0x34/0x40)
|[<
c01e1ff4>] (musb_giveback+0x34/0x40) from [<
c01e2b1c>] (musb_advance_schedule+0xb4/0x1c0)
|[<
c01e2b1c>] (musb_advance_schedule+0xb4/0x1c0) from [<
c01e2ca8>] (musb_cleanup_urb.isra.9+0x80/0x8c)
|[<
c01e2ca8>] (musb_cleanup_urb.isra.9+0x80/0x8c) from [<
c01e2ed0>] (musb_urb_dequeue+0xec/0x108)
|[<
c01e2ed0>] (musb_urb_dequeue+0xec/0x108) from [<
c01cbb90>] (unlink1+0xbc/0xcc)
|[<
c01cbb90>] (unlink1+0xbc/0xcc) from [<
c01cc2ec>] (usb_hcd_unlink_urb+0x54/0xa8)
|[<
c01cc2ec>] (usb_hcd_unlink_urb+0x54/0xa8) from [<
c01c2a84>] (unlink_urbs.isra.17+0x2c/0x58)
|[<
c01c2a84>] (unlink_urbs.isra.17+0x2c/0x58) from [<
c01c2b44>] (usbnet_terminate_urbs+0x94/0x10c)
|[<
c01c2b44>] (usbnet_terminate_urbs+0x94/0x10c) from [<
c01c2d68>] (usbnet_stop+0x100/0x15c)
|[<
c01c2d68>] (usbnet_stop+0x100/0x15c) from [<
c020f718>] (__dev_close_many+0x94/0xc8)
defer_bh() takes the lock which is hold during unlink_urbs(). The safe
walk suggest that the skb will be removed from the list and this is done
by defer_bh() so it seems to be okay to drop the lock here.
Cc: stable@kernel.org
Reported-by: AnÃbal Almeida Pinto <anibal.pinto@efacec.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jeff Layton [Thu, 23 Feb 2012 14:37:45 +0000 (09:37 -0500)]
cifs: fix dentry refcount leak when opening a FIFO on lookup
commit
5bccda0ebc7c0331b81ac47d39e4b920b198b2cd upstream.
The cifs code will attempt to open files on lookup under certain
circumstances. What happens though if we find that the file we opened
was actually a FIFO or other special file?
Currently, the open filehandle just ends up being leaked leading to
a dentry refcount mismatch and oops on umount. Fix this by having the
code close the filehandle on the server if it turns out not to be a
regular file. While we're at it, change this spaghetti if statement
into a switch too.
Cc: stable@vger.kernel.org
Reported-by: CAI Qian <caiqian@redhat.com>
Tested-by: CAI Qian <caiqian@redhat.com>
Reviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
David Howells [Fri, 24 Feb 2012 17:01:27 +0000 (18:01 +0100)]
KEYS: Enable the compat keyctl wrapper on s390x
commit
1d057720609ed052a6371fe1d53300e5e6328e94 upstream.
Enable the compat keyctl wrapper on s390x so that 32-bit s390 userspace can
call the keyctl() syscall.
There's an s390x assembly wrapper that truncates all the register values to
32-bits and this then calls compat_sys_keyctl() - but the latter only exists if
CONFIG_KEYS_COMPAT is enabled, and the s390 Kconfig doesn't enable it.
Without this patch, 32-bit calls to the keyctl() syscall are given an ENOSYS
error:
[root@devel4 ~]# keyctl show
Session Keyring
-3: key inaccessible (Function not implemented)
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: dan@danny.cz
Cc: Carsten Otte <cotte@de.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Tyler Hicks [Tue, 6 Mar 2012 16:16:47 +0000 (09:16 -0700)]
eCryptfs: Handle failed metadata read in lookup
When failing to read the lower file's crypto metadata during a lookup,
eCryptfs must continue on without throwing an error. For example, there
may be a plaintext file in the lower mount point that the user wants to
delete through the eCryptfs mount.
If an error is encountered while reading the metadata in lookup(), the
eCryptfs inode's size could be incorrect. We must be sure to reread the
plaintext inode size from the metadata when performing an open() or
setattr(). The metadata is already being read in those paths, so this
adds minimal performance overhead.
This patch introduces a flag which will track whether or not the
plaintext inode size has been read so that an incorrect i_size can be
fixed in the open() or setattr() paths.
BugLink: http://bugs.launchpad.net/bugs/509180
https://lists.ubuntu.com/archives/kernel-team/2012-March/019137.html
Cc: <stable@kernel.org>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
(backported from
3aeb86ea4cd15f728147a3bd5469a205ada8c767)
Cc: Tyler Hicks <tyler.hicks@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Stanislaw Gruszka [Mon, 5 Mar 2012 21:28:26 +0000 (14:28 -0700)]
bsg: fix sysfs link remove warning
BugLink: http://bugs.launchpad.net/bugs/946928
We create "bsg" link if q->kobj.sd is not NULL, so remove it only
when the same condition is true.
Fixes:
WARNING: at fs/sysfs/inode.c:323 sysfs_hash_and_remove+0x2b/0x77()
sysfs: can not remove 'bsg', no directory
Call Trace:
[<
c0429683>] warn_slowpath_common+0x6a/0x7f
[<
c0537a68>] ? sysfs_hash_and_remove+0x2b/0x77
[<
c042970b>] warn_slowpath_fmt+0x2b/0x2f
[<
c0537a68>] sysfs_hash_and_remove+0x2b/0x77
[<
c053969a>] sysfs_remove_link+0x20/0x23
[<
c05d88f1>] bsg_unregister_queue+0x40/0x6d
[<
c0692263>] __scsi_remove_device+0x31/0x9d
[<
c069149f>] scsi_forget_host+0x41/0x52
[<
c0689fa9>] scsi_remove_host+0x71/0xe0
[<
f7de5945>] quiesce_and_remove_host+0x51/0x83 [usb_storage]
[<
f7de5a1e>] usb_stor_disconnect+0x18/0x22 [usb_storage]
[<
c06c29de>] usb_unbind_interface+0x4e/0x109
[<
c067a80f>] __device_release_driver+0x6b/0xa6
[<
c067a861>] device_release_driver+0x17/0x22
[<
c067a46a>] bus_remove_device+0xd6/0xe6
[<
c06785e2>] device_del+0xf2/0x137
[<
c06c101f>] usb_disable_device+0x94/0x1a0
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit
37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Jens Axboe [Fri, 21 May 2010 18:00:35 +0000 (20:00 +0200)]
writeback: fixups for !dirty_writeback_centisecs
commit
6423104b6a1e6f0c18be60e8c33f02d263331d5e upstream.
Commit
69b62d01 fixed up most of the places where we would enter
busy schedule() spins when disabling the periodic background
writeback. This fixes up the sb timer so that it doesn't get
hammered on with the delay disabled, and ensures that it gets
rearmed if needed when /proc/sys/vm/dirty_writeback_centisecs
gets modified.
bdi_forker_task() also needs to check for !dirty_writeback_centisecs
and use schedule() appropriately, fix that up too.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Tested-by: Xavier Roche <roche@httrack.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Ben Hutchings [Fri, 9 Mar 2012 04:21:03 +0000 (04:21 +0000)]
IA64: Remove COMPAT_IA32 support
commit
32974ad4907cdde6c9de612cd1b2ee0568fb9409 upstream
This just changes Kconfig rather than touching all the other files the
original commit did.
Patch description from the original commit :
| [IA64] Remove COMPAT_IA32 support
|
| This has been broken since May 2008 when Al Viro killed altroot support.
| Since nobody has complained, it would appear that there are no users of
| this code (A plausible theory since the main OSVs that support ia64 prefer
| to use the IA32-EL software emulation).
|
| Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Heiko Carstens [Mon, 5 Mar 2012 13:06:38 +0000 (14:06 +0100)]
compat: Re-add missing asm/compat.h include to fix compile breakage on s390
For kernels < 3.0 the backport of
048cd4e51d24ebf7f3552226d03c769d6ad91658
"compat: fix compile breakage on s390" will break compilation...
Re-add a single #include <asm/compat.h> in order to fix this.
This patch is _not_ necessary for upstream, only for stable kernels
which include the "build fix" mentioned above.
Reported-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Greg Kroah-Hartman [Sun, 4 Mar 2012 17:49:44 +0000 (09:49 -0800)]
Linux 2.6.32.58
Tetsuo Handa [Wed, 29 Feb 2012 06:54:56 +0000 (12:24 +0530)]
PM / Sleep: Fix read_unlock_usermodehelper() call.
[ Upstream commit
e4c89a508f4385a0cd8681c2749a2cd2fa476e40 ]
Commit
b298d289
"PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()"
added read_unlock_usermodehelper() but read_unlock_usermodehelper() is called
without read_lock_usermodehelper() when kmalloc() failed.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / unionfs-2.6.39.y.git / log