linux-stable.git/include, branch v3.0.4

Add a personality to report 2.6.x version numbers

2011-08-29T20:29:16+00:00

commit be27425dcc516fd08245b047ea57f83b8f6f0903 upstream.

I ran into a couple of programs which broke with the new Linux 3.0
version. Some of those were binary only. I tried to use LD_PRELOAD to
work around it, but it was quite difficult and in one case impossible
because of a mix of 32bit and 64bit executables.

For example, all kind of management software from HP doesnt work, unless
we pretend to run a 2.6 kernel.

$ uname -a
Linux svivoipvnx001 3.0.0-08107-g97cd98f #1062 SMP Fri Aug 12 18:11:45 CEST 2011 i686 i686 i386 GNU/Linux

$ hpacucli ctrl all show

Error: No controllers detected.

$ rpm -qf /usr/sbin/hpacucli
hpacucli-8.75-12.0

Another notable case is that Python now reports "linux3" from
sys.platform(); which in turn can break things that were checking
sys.platform() == "linux2":

https://bugzilla.mozilla.org/show_bug.cgi?id=664564

It seems pretty clear to me though it's a bug in the apps that are using
'==' instead of .startswith(), but this allows us to unbreak broken
programs.

This patch adds a UNAME26 personality that makes the kernel report a
2.6.40+x version number instead. The x is the x in 3.x.

I know this is somewhat ugly, but I didn't find a better workaround, and
compatibility to existing programs is important.

Some programs also read /proc/sys/kernel/osrelease. This can be worked
around in user space with mount --bind (and a mount namespace)

To use:

wget ftp://ftp.kernel.org/pub/linux/kernel/people/ak/uname26/uname26.c
gcc -o uname26 uname26.c
./uname26 program

Signed-off-by: Andi Kleen
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman

x86, mtrr: lock stop machine during MTRR rendezvous sequence

2011-08-29T20:29:08+00:00

commit 6d3321e8e2b3bf6a5892e2ef673c7bf536e3f904 upstream.

MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially
happen in parallel with another system wide rendezvous using
stop_machine(). This can lead to deadlock (The order in which
works are queued can be different on different cpu's. Some cpu's
will be running the first rendezvous handler and others will be running
the second rendezvous handler. Each set waiting for the other set to join
for the system wide rendezvous, leading to a deadlock).

MTRR rendezvous sequence is not implemented using stop_machine() as this
gets called both from the process context aswell as the cpu online paths
(where the cpu has not come online and the interrupts are disabled etc).
stop_machine() works with only online cpus.

For now, take the stop_machine mutex in the MTRR rendezvous sequence that
gets called from an online cpu (here we are in the process context
and can potentially sleep while taking the mutex). And the MTRR rendezvous
that gets triggered during cpu online doesn't need to take this stop_machine
lock (as the stop_machine() already ensures that there is no cpu hotplug
going on in parallel by doing get_online_cpus())

    TBD: Pursue a cleaner solution of extending the stop_machine()
         infrastructure to handle the case where the calling cpu is
         still not online and use this for MTRR rendezvous sequence.

fixes: https://bugzilla.novell.com/show_bug.cgi?id=672008

Reported-by: Vadim Kotelnikov 
Signed-off-by: Suresh Siddha 
Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.com
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

mm: Fix fixup_user_fault() for MMU=n

2011-08-16T01:31:43+00:00

commit 5c723ba5b7886909b2e430f2eae454c33f7fe5c6 upstream.

In commit 2efaca927f5c ("mm/futex: fix futex writes on archs with SW
tracking of dirty & young") we forgot about MMU=n.  This patch fixes
that.

Signed-off-by: Peter Zijlstra 
Acked-by: Benjamin Herrenschmidt 
Acked-by: David Howells 
Link: http://lkml.kernel.org/r/1311761831.24752.413.camel@twins
Signed-off-by: Linus Torvalds 
Cc: Mike Frysinger 
Signed-off-by: Greg Kroah-Hartman

net: add IFF_SKB_TX_SHARED flag to priv_flags

2011-08-16T01:31:38+00:00

[ Upstream commit d8873315065f1f527c7c380402cf59b1e1d0ae36 ]

Pktgen attempts to transmit shared skbs to net devices, which can't be used by
some drivers as they keep state information in skbs.  This patch adds a flag
marking drivers as being able to handle shared skbs in their tx path.  Drivers
are defaulted to being unable to do so, but calling ether_setup enables this
flag, as 90% of the drivers calling ether_setup touch real hardware and can
handle shared skbs.  A subsequent patch will audit drivers to ensure that the
flag is set properly

Signed-off-by: Neil Horman 
Reported-by: Jiri Pirko 
CC: Robert Olsson 
CC: Eric Dumazet 
CC: Alexey Dobriyan 
CC: David S. Miller 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: make fragment identifications less predictable

2011-08-16T01:31:37+00:00

[ Backport of upstream commit 87c48fa3b4630905f98268dde838ee43626a060c ]

Fernando Gont reported current IPv6 fragment identification generation
was not secure, because using a very predictable system-wide generator,
allowing various attacks.

IPv4 uses inetpeer cache to address this problem and to get good
performance. We'll use this mechanism when IPv6 inetpeer is stable
enough in linux-3.1

For the time being, we use jhash on destination address to provide less
predictable identifications. Also remove a spinlock and use cmpxchg() to
get better SMP performance.

Reported-by: Fernando Gont 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: Compute protocol sequence numbers and fragment IDs using MD5.

2011-08-16T01:31:35+00:00

Computers have become a lot faster since we compromised on the
partial MD4 hash which we use currently for performance reasons.

MD5 is a much safer choice, and is inline with both RFC1948 and
other ISS generators (OpenBSD, Solaris, etc.)

Furthermore, only having 24-bits of the sequence number be truly
unpredictable is a very serious limitation.  So the periodic
regeneration and 8-bit counter have been removed.  We compute and
use a full 32-bit sequence number.

For ipv6, DCCP was found to use a 32-bit truncated initial sequence
number (it needs 43-bits) and that is fixed here as well.

Reported-by: Dan Kaminsky 
Tested-by: Willy Tarreau 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

crypto: Move md5_transform to lib/md5.c

2011-08-16T01:31:35+00:00

We are going to use this for TCP/IP sequence number and fragment ID
generation.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix typo in DRM_I915_OVERLAY_PUT_IMAGE ioctl define

2011-08-16T01:31:35+00:00

commit 842d452985300f4ec14c68cb86046e8a1a3b7251 upstream.

Because of a typo, calling ioctl with DRM_IOCTL_I915_OVERLAY_PUT_IMAGE
is broken if the macro is used directly. When using libdrm the bug is
not hit, since libdrm handles the ioctl encoding internally.

The typo also leads to the .cmd and .cmd_drv fields of the drm_ioctl
structure for DRM_I915_OVERLAY_PUT_IMAGE having inconsistent content.

Signed-off-by: Ole Henrik Jahren 
Acked-by: Daniel Vetter 
Signed-off-by: Keith Packard 
Signed-off-by: Greg Kroah-Hartman

drm: Separate EDID Header Check from EDID Block Check

2011-08-16T01:31:34+00:00

commit 051963d4832ed61e5ae74f5330b0a94489e101b9 upstream.

    Provides function drm_edid_header_is_valid() for EDID header check
    and replaces EDID header check part of function drm_edid_block_valid()
    by a call of drm_edid_header_is_valid().
    This is a prerequisite to extend DDC probing, e. g. in function
    radeon_ddc_probe() for Radeon devices, by a central EDID header check.

    Tested for kernel 2.6.35, 2.6.38 and 3.0

Signed-off-by: Thomas Reim 
Reviewed-by: Alex Deucher 
Acked-by: Stephen Michaels 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

xen: allow enable use of VGA console on dom0

2011-08-16T01:31:34+00:00

commit c2419b4a4727f67af2fc2cd68b0d878b75e781bb upstream.

Get the information about the VGA console hardware from Xen, and put
it into the form the bootloader normally generates, so that the rest
of the kernel can deal with VGA as usual.

[ Impact: make VGA console work in dom0 ]

Signed-off-by: Jeremy Fitzhardinge 
[v1: Rebased on 2.6.39]
[v2: Removed incorrect comments and fixed compile warnings]
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman