linux-stable.git/Documentation, branch v3.2.66

Documentation: lzo: document part of the encoding

2014-12-14T16:23:45+00:00

commit d98a0526434d27e261f622cf9d2e0028b5ff1a00 upstream.

Add a complete description of the LZO format as processed by the
decompressor. I have not found a public specification of this format
hence this analysis, which will be used to better understand the code.

Cc: Willem Pinckaers 
Cc: "Don A. Bailey" 
Signed-off-by: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack

2014-09-13T22:41:51+00:00

commit 3891a04aafd668686239349ea58f3314ea2af86b upstream.

The IRET instruction, when returning to a 16-bit segment, only
restores the bottom 16 bits of the user space stack pointer.  This
causes some 16-bit software to break, but it also leaks kernel state
to user space.  We have a software workaround for that ("espfix") for
the 32-bit kernel, but it relies on a nonzero stack segment base which
is not available in 64-bit mode.

In checkin:

    b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

we "solved" this by forbidding 16-bit segments on 64-bit kernels, with
the logic that 16-bit support is crippled on 64-bit kernels anyway (no
V86 support), but it turns out that people are doing stuff like
running old Win16 binaries under Wine and expect it to work.

This works around this by creating percpu "ministacks", each of which
is mapped 2^16 times 64K apart.  When we detect that the return SS is
on the LDT, we copy the IRET frame to the ministack and use the
relevant alias to return to userspace.  The ministacks are mapped
readonly, so if IRET faults we promote #GP to #DF which is an IST
vector and thus has its own stack; we then do the fixup in the #DF
handler.

(Making #GP an IST exception would make the msr_safe functions unsafe
in NMI/MC context, and quite possibly have other effects.)

Special thanks to:

- Andy Lutomirski, for the suggestion of using very small stack slots
  and copy (as opposed to map) the IRET frame there, and for the
  suggestion to mark them readonly and let the fault promote to #DF.
- Konrad Wilk for paravirt fixup and testing.
- Borislav Petkov for testing help and useful comments.

Reported-by: Brian Gerst 
Signed-off-by: H. Peter Anvin 
Link: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com
Cc: Konrad Rzeszutek Wilk 
Cc: Borislav Petkov 
Cc: Andrew Lutomriski 
Cc: Linus Torvalds 
Cc: Dirk Hohndel 
Cc: Arjan van de Ven 
Cc: comex 
Cc: Alexander van Heukelum 
Cc: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

ALSA: virtuoso: add Xonar Essence STX II support

2014-09-13T22:41:42+00:00

commit f42bb22243d2ae264d721b055f836059fe35321f upstream.

Just add the PCI ID for the STX II.  It appears to work the same as the
STX, except for the addition of the not-yet-supported daughterboard.

Tested-by: Mario 
Tested-by: corubba 
Signed-off-by: Clemens Ladisch 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

stable_kernel_rules: Add pointer to netdev-FAQ for network patches

2014-09-13T22:41:37+00:00

commit b76fc285337b6b256e9ba20a40cfd043f70c27af upstream.

Stable_kernel_rules should point submitters of network stable patches to the
netdev_FAQ.txt as requests for stable network patches should go to netdev
first.

Signed-off-by: Dave Chiluk 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

Documentation: Update stable address in Chinese and Japanese translations

2014-07-11T12:33:59+00:00

commit 98b0f811aade1b7c6e7806c86aa0befd5919d65f upstream.

The English and Korean translations were updated, the Chinese and Japanese
weren't.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

Input: elantech - fix touchpad initialization on Gigabyte U2442

2014-06-09T12:29:08+00:00

commit 36189cc3cd57ab0f1cd75241f93fe01de928ac06 upstream.

The hw_version 3 Elantech touchpad on the Gigabyte U2442 does not accept
0x0b as initialization value for r10, this stand-alone version of the
driver: http://planet76.com/drivers/elantech/psmouse-elantech-v6.tar.bz2

Uses 0x03 which does work, so this means not setting bit 3 of r10 which
sets: "Enable Real H/W Resolution In Absolute mode"

Which will result in half the x and y resolution we get with that bit set,
so simply not setting it everywhere is not a solution. We've been unable to
find a way to identify touchpads where setting the bit will fail, so this
patch uses a dmi based blacklist for this.

https://bugzilla.kernel.org/show_bug.cgi?id=61151

Reported-by: Philipp Wolfer 
Tested-by: Philipp Wolfer 
Signed-off-by: Hans de Goede 
Signed-off-by: Dmitry Torokhov 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

media: gspca: sn9c20x: add ID for Genius Look 1320 V2

2014-04-30T15:23:20+00:00

commit 61f0319193c44adbbada920162d880b1fdb3aeb3 upstream.

Signed-off-by: Wolfram Sang 
Signed-off-by: Hans de Goede 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

mm, oom: base root bonus on current usage

2014-04-01T23:58:46+00:00

commit 778c14affaf94a9e4953179d3e13a544ccce7707 upstream.

A 3% of system memory bonus is sometimes too excessive in comparison to
other processes.

With commit a63d83f427fb ("oom: badness heuristic rewrite"), the OOM
killer tries to avoid killing privileged tasks by subtracting 3% of
overall memory (system or cgroup) from their per-task consumption.  But
as a result, all root tasks that consume less than 3% of overall memory
are considered equal, and so it only takes 33+ privileged tasks pushing
the system out of memory for the OOM killer to do something stupid and
kill dhclient or other root-owned processes.  For example, on a 32G
machine it can't tell the difference between the 1M agetty and the 10G
fork bomb member.

The changelog describes this 3% boost as the equivalent to the global
overcommit limit being 3% higher for privileged tasks, but this is not
the same as discounting 3% of overall memory from _every privileged task
individually_ during OOM selection.

Replace the 3% of system memory bonus with a 3% of current memory usage
bonus.

By giving root tasks a bonus that is proportional to their actual size,
they remain comparable even when relatively small.  In the example
above, the OOM killer will discount the 1M agetty's 256 badness points
down to 179, and the 10G fork bomb's 262144 points down to 183500 points
and make the right choice, instead of discounting both to 0 and killing
agetty because it's first in the task list.

Signed-off-by: David Rientjes 
Reported-by: Johannes Weiner 
Acked-by: Johannes Weiner 
Cc: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2: existing code changes 'points' directly rather
 than using 'adj' variable]
Signed-off-by: Ben Hutchings

i2c: piix4: Add support for AMD ML and CZ SMBus changes

2014-04-01T23:58:45+00:00

commit 032f708bc4f6da868ec49dac48ddf3670d8035d3 upstream.

The locations of SMBus register base address and enablement bit are changed
from AMD ML, which need this patch to be supported.

Signed-off-by: Shane Huang 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
[bwh: Backported to 3.2:
 - Adjust context
 - Aux bus support is not included]
Signed-off-by: Ben Hutchings

libata: disable a disk via libata.force params

2014-02-15T19:20:13+00:00

commit b8bd6dc36186fe99afa7b73e9e2d9a98ad5c4865 upstream.

A user on StackExchange had a failing SSD that's soldered directly
onto the motherboard of his system. The BIOS does not give any option
to disable it at all, so he can't just hide it from the OS via the
BIOS.

The old IDE layer had hdX=noprobe override for situations like this,
but that was never ported to the libata layer.

This patch implements a disable flag for libata.force.

Example use:

 libata.force=2.0:disable

[v2 of the patch, removed the nodisable flag per Tejun Heo]

Signed-off-by: Robin H. Johnson 
Signed-off-by: Tejun Heo 
Link: http://unix.stackexchange.com/questions/102648/how-to-tell-linux-kernel-3-0-to-completely-ignore-a-failing-disk
Link: http://askubuntu.com/questions/352836/how-can-i-tell-linux-kernel-to-completely-ignore-a-disk-as-if-it-was-not-even-co
Link: http://superuser.com/questions/599333/how-to-disable-kernel-probing-for-drive
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings