~thopiekar/linux/+git/linux-stable:linux-2.6.34.y
- Git
- lp:~thopiekar/linux/+git/linux-stable
- linux-2.6.34.y
- Get this branch:
-
git clone
-b linux-2.6.34.y
https://git.launchpad.net/~thopiekar/linux/+git/linux-stable
Branch merges
Related source package recipes
Branch information
- Name:
- linux-2.6.34.y
- Repository:
- lp:~thopiekar/linux/+git/linux-stable
Recent commits
- 5878e06... by Paul Gortmaker <email address hidden>
-
Linux 2.6.34.15
Signed-off-by: Paul Gortmaker <email address hidden>
- dbe686b... by Wang YanQing
-
video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
commit b78f29ca0516266
431688c5eb42d39 ce42ec039a 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 <email address hidden>
Cc: Michal Januszewski <email address hidden>
Cc: Alan Cox <email address hidden>
Signed-off-by: Florian Tobias Schandinat <email address hidden>
Signed-off-by: Paul Gortmaker <email address hidden> - 9407270... by Kent Yoder <email address hidden>
-
crypto: sha512 - Fix byte counter overflow in SHA-512
commit 25c3d30c9182075
56ae1d6e663150e bdf902186b 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 <email address hidden>
Signed-off-by: Herbert Xu <email address hidden>
Signed-off-by: Paul Gortmaker <email address hidden> - f126b9e... by Thomas Jarosch
-
PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs
commit cdb1f35dc7de428
02527140a361387 1c394548e1 upstream. commit f67fd55fa96f7d7
295b43ffbc4a97d 8f55e473aa 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 <email address hidden>
Tested-by: Charlie Suffin <email address hidden>
Signed-off-by: Jesse Barnes <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Paul Gortmaker <email address hidden> - 00d23e7... by Sasha Levin
-
phonet: Check input from user before allocating
commit bcf1b70ac6eb0ed
8286c66e6bf37cb 747cbaa04c upstream. 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 <email address hidden>
Acked-by: RĂ©mi Denis-Courmont <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Paul Gortmaker <email address hidden> - bcbb4d0... by Pavel Shilovsky <email address hidden>
-
fuse: fix stat call on 32 bit platforms
commit 45c72cd73c788dd
18c8113d4a404d6 b4a01decf1 upstream. Now we store attr->ino at inode->i_ino, return attr->ino at the
first time and then return inode->i_ino if the attribute timeout
isn't expired. That's wrong on 32 bit platforms because attr->ino
is 64 bit and inode->i_ino is 32 bit in this case.Fix this by saving 64 bit ino in fuse_inode structure and returning
it every time we call getattr. Also squash attr->ino into inode->i_ino
explicitly.Signed-off-by: Pavel Shilovsky <email address hidden>
Signed-off-by: Miklos Szeredi <email address hidden>
Signed-off-by: Paul Gortmaker <email address hidden> - a02302d... by Tyler Hicks
-
eCryptfs: Properly check for O_RDONLY flag before doing privileged open
commit 9fe79d7600497ed
8a95c3981cbe5b7 3ab98222f0 upstream. If the first attempt at opening the lower file read/write fails,
eCryptfs will retry using a privileged kthread. However, the privileged
retry should not happen if the lower file's inode is read-only because a
read/write open will still be unsuccessful.The check for determining if the open should be retried was intended to
be based on the access mode of the lower file's open flags being
O_RDONLY, but the check was incorrectly performed. This would cause the
open to be retried by the privileged kthread, resulting in a second
failed open of the lower file. This patch corrects the check to
determine if the open request should be handled by the privileged
kthread.Signed-off-by: Tyler Hicks <email address hidden>
Reported-by: Dan Carpenter <email address hidden>
Acked-by: Dan Carpenter <email address hidden>
Signed-off-by: Paul Gortmaker <email address hidden> - 177fa7d... by Dan Williams
-
fix eh wakeup (scsi_schedule_eh vs scsi_restart_
operations) commit 57fc2e335fd3c2f
898ee73570dc814 26c28dc7b4 upstream. Rapid ata hotplug on a libsas controller results in cases where libsas
is waiting indefinitely on eh to perform an ata probe.A race exists between scsi_schedule_eh() and scsi_restart_
operations( )
in the case when scsi_restart_operations( ) issues i/o to other devices
in the sas domain. When this happens the host state transitions from
SHOST_RECOVERY (set by scsi_schedule_eh) back to SHOST_RUNNING and
->host_busy is non-zero so we put the eh thread to sleep even though
->host_eh_scheduled is active.Before putting the error handler to sleep we need to check if the
host_state needs to return to SHOST_RECOVERY for another trip through
eh. Since i/o that is released by scsi_restart_operations has been
blocked for at least one eh cycle, this implementation allows those
i/o's to run before another eh cycle starts to discourage hung task
timeouts.Reported-by: Tom Jackson <email address hidden>
Tested-by: Tom Jackson <email address hidden>
Signed-off-by: Dan Williams <email address hidden>
Signed-off-by: James Bottomley <email address hidden>
Signed-off-by: Paul Gortmaker <email address hidden> - c3997b4... by Dan Williams
-
SCSI: libsas: fix sas_discover_
devices return code handling commit e69e5d3d25d6b58
543f782a515baed a064e2b601 upstream. commit b17caa174a7e1fd
2e17b26e210d4ee 91c4c28b37 upstream. commit 198439e4 [SCSI] libsas: do not set res = 0 in sas_ex_
discover_ dev()
commit 19252de6 [SCSI] libsas: fix wide port hotplug issuesThe above commits seem to have confused the return value of
sas_ex_discover_dev which is non-zero on failure and
sas_ex_join_wide_ port which just indicates short circuiting discovery on
already established ports. The result is random discovery failures
depending on configuration.Calls to sas_ex_
join_wide_ port are the source of the trouble as its
return value is errantly assigned to 'res'. Convert it to bool and stop
returning its result up the stack.Tested-by: Dan Melnic <email address hidden>
Reported-by: Dan Melnic <email address hidden>
Signed-off-by: Dan Williams <email address hidden>
Reviewed-by: Jack Wang <email address hidden>
Signed-off-by: James Bottomley <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Paul Gortmaker <email address hidden> - 7888dfe... by Dan Williams
-
libsas: continue revalidation
commit 26f2f199ff150d8
876b2641c41e60d 1c92d2fb81 upstream. Continue running revalidation until no more broadcast devices are
discovered. Fixes cases where re-discovery completes too early in a
domain with multiple expanders with pending re-discovery events.
Servicing BCNs can get backed up behind error recovery.Signed-off-by: Dan Williams <email address hidden>
Signed-off-by: James Bottomley <email address hidden>
Signed-off-by: Paul Gortmaker <email address hidden>