kernel/linux.git/drivers/char, branch linux-2.6.35.y

hvc_console: Improve tty/console put_chars handling

2011-08-01T20:55:01+00:00

[ upstream commit 8c2381af0d3ef62a681dac5a141b6dabb27bf2e1 ] Currently, the hvc_console_print() function drops console output if the hvc backend's put_chars() returns 0. This patch changes this behavior to allow a retry through returning -EAGAIN. This change also affects the hvc_push() function. Both functions are changed to handle -EAGAIN and to retry the put_chars() operation. If a hvc backend returns -EAGAIN, the retry handling differs: - hvc_console_print() spins to write the complete console output. - hvc_push() behaves the same way as for returning 0. Now hvc backends can indirectly control the way how console output is handled through the hvc console layer. Signed-off-by: Hendrik Brueckner Acked-by: Anton Blanchard Cc: Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Andi Kleen

i8k: Avoid lahf in 64-bit code

2011-08-01T20:54:53+00:00

commit bc1f419c76a2d6450413ce4349f4e4a07be011d5 upstream. i8k uses lahf to read the flag register in 64-bit code; early x86-64 CPUs, however, lack this instruction and we get an invalid opcode exception at runtime. Use pushf to load the flag register into the stack instead. Signed-off-by: Luca Tettamanti Reported-by: Jeff Rickman Tested-by: Jeff Rickman Tested-by: Harry G McGavran Jr Cc: Massimo Dal Zotto Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

Fix gcc 4.5.1 miscompiling drivers/char/i8k.c (again)

2011-08-01T20:54:41+00:00

[ upstream commit 22d3243de86bc92d874abb7c5b185d5c47aba323 ] The fix in commit 6b4e81db2552 ("i8k: Tell gcc that *regs gets clobbered") to work around the gcc miscompiling i8k.c to add "+m (*regs)" caused register pressure problems and a build failure. Changing the 'asm' statement to 'asm volatile' instead should prevent that and works around the gcc bug as well, so we can remove the "+m". [ Background on the gcc bug: a memory clobber fails to mark the function the asm resides in as non-pure (aka "__attribute__((const))"), so if the function does nothing else that triggers the non-pure logic, gcc will think that that function has no side effects at all. As a result, callers will be mis-compiled. Adding the "+m" made gcc see that it's not a pure function, and so does "asm volatile". The problem was never really the need to mark "*regs" as changed, since the memory clobber did that part - the problem was just a bug in the gcc "pure" function analysis - Linus ] Signed-off-by: Jim Bos Acked-by: Jakub Jelinek Cc: Andi Kleen Cc: Andreas Schwab Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen

i8k: Tell gcc that *regs gets clobbered

2011-08-01T20:54:41+00:00

[ upstream commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48 ] More recent GCC caused the i8k driver to stop working, on Slackware compiler was upgraded from gcc-4.4.4 to gcc-4.5.1 after which it didn't work anymore, meaning the driver didn't load or gave total nonsensical output. As it turned out the asm(..) statement forgot to mention it modifies the *regs variable. Credits to Andi Kleen and Andreas Schwab for providing the fix. Signed-off-by: Jim Bos Cc: Andi Kleen Cc: Andreas Schwab Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen

agp: fix OOM and buffer overflow

2011-08-01T20:54:41+00:00

[ upstream commit b522f02184b413955f3bc952e3776ce41edc6355 ] page_count is copied from userspace. agp_allocate_memory() tries to check whether this number is too big, but doesn't take into account the wrap case. Also agp_create_user_memory() doesn't check whether alloc_size is calculated from num_agp_pages variable without overflow. This may lead to allocation of too small buffer with following buffer overflow. Another problem in agp code is not addressed in the patch - kernel memory exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls). It is not checked whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()). Each allocation is limited to 16KB, though, there is no per-process limit. This might lead to OOM situation, which is not even solved in case of the caller death by OOM killer - the memory is allocated for another (faked) process. Signed-off-by: Vasiliy Kulikov Signed-off-by: Dave Airlie Signed-off-by: Andi Kleen

agp: fix arbitrary kernel memory writes

2011-08-01T20:54:41+00:00

[ upstream commit 194b3da873fd334ef183806db751473512af29ce ] pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl cmds of agp_ioctl() and passed to agpioc_bind_wrap(). As said in the comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND, and it is not checked at all in case of AGPIOC_UNBIND. As a result, user with sufficient privileges (usually "video" group) may generate either local DoS or privilege escalation. Signed-off-by: Vasiliy Kulikov Signed-off-by: Dave Airlie Signed-off-by: Andi Kleen

Revert "tpm_tis: Use timeouts returned from TPM"

2011-04-28T15:21:16+00:00

[ upstream commit e58713724059da7d2982d6ad945192c8fca5b729 ] This reverts commit 9b29050f8f75916f974a2d231ae5d3cd59792296. It has caused hibernate regressions, for example Juri Sladby's report: "I'm unable to hibernate 2.6.37.1 unless I rmmod tpm_tis: [10974.074587] Suspending console(s) (use no_console_suspend to debug) [10974.103073] tpm_tis 00:0c: Operation Timed out [10974.103089] legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -62 [10974.103095] PM: Device 00:0c failed to freeze: error -62" and Rafael points out that some of the new conditionals in that commit seem to make no sense. This commit needs more work and testing, let's revert it for now. Reported-by: Norbert Preining Reported-and-requested-by: Jiri Slaby Cc: Stefan Berger Cc: Guillaume Chazarain Cc: Rajiv Andrade Acked-by: Rafael J. Wysocki Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen

Revert "TPM: Long default timeout fix"

2011-04-28T15:21:16+00:00

[ upstream commit 8d1dc20e8d689c7e6a0a4d2c94e36a99d5793ecb ] This reverts commit c4ff4b829ef9e6353c0b133b7adb564a68054979. Ted Ts'o reports: "TPM is working for me so I can log into employer's network in 2.6.37. It broke when I tried 2.6.38-rc6, with the following relevant lines from my dmesg: [ 11.081627] tpm_tis 00:0b: 1.2 TPM (device-id 0x0, rev-id 78) [ 25.734114] tpm_tis 00:0b: Operation Timed out [ 78.040949] tpm_tis 00:0b: Operation Timed out This caused me to get suspicious, especially since the _other_ TPM commit in 2.6.38 had already been reverted, so I tried reverting commit c4ff4b829e: "TPM: Long default timeout fix". With this commit reverted, my TPM on my Lenovo T410 is once again working." Requested-and-tested-by: Theodore Ts'o Acked-by: Rajiv Andrade Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen

char/tpm: Fix unitialized usage of data buffer

2011-04-28T15:20:56+00:00

commit 1309d7afbed112f0e8e90be9af975550caa0076b upstream. This patch fixes information leakage to the userspace by initializing the data buffer to zero. Reported-by: Peter Huewe Signed-off-by: Peter Huewe Signed-off-by: Marcel Selhorst Signed-off-by: Andi Kleen [ Also removed the silly "* sizeof(u8)". If that isn't 1, we have way deeper problems than a simple multiplication can fix. - Linus ] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

tpm_tis: Use timeouts returned from TPM

2011-03-31T18:57:54+00:00

commit 9b29050f8f75916f974a2d231ae5d3cd59792296 upstream. The current TPM TIS driver in git discards the timeout values returned from the TPM. The check of the response packet needs to consider that the return_code field is 0 on success and the size of the expected packet is equivalent to the header size + u32 length indicator for the TPM_GetCapability() result + 3 timeout indicators of type u32. I am also adding a sysfs entry 'timeouts' showing the timeouts that are being used. Signed-off-by: Stefan Berger Signed-off-by: Andi Kleen Tested-by: Guillaume Chazarain Signed-off-by: Rajiv Andrade Signed-off-by: Greg Kroah-Hartman