Linux 3.0.69

commit b86163d5a3c2f913bc5546770d3a6b6a2dd3698b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Mar 14 11:32:24 2013 -0700

    Linux 3.0.69

commit 3241d80d48900fc43535980865f1ef726af68713
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Fri Mar 8 12:43:32 2013 -0800

    dmi_scan: fix missing check for _DMI_ signature in smbios_present()

    commit a40e7cf8f06b4e322ba902e4e9f6a6b0c2daa907 upstream.

    Commit 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version
    from SMBIOS if it exists") hoisted the check for "_DMI_" into
    dmi_scan_machine(), which means that we don't bother to check for
    "_DMI_" at offset 16 in an SMBIOS entry.  smbios_present() may also call
    dmi_present() for an address where we found "_SM_", if it failed further
    validation.

    Check for "_DMI_" in smbios_present() before calling dmi_present().

    [akpm@linux-foundation.org: fix build]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Reported-by: Tim McGrath <tmhikaru@gmail.com>
    Tested-by: Tim Mcgrath <tmhikaru@gmail.com>
    Cc: Zhenzhong Duan <zhenzhong.duan@oracle.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>

commit cf8b9671f59ce789d852c7cf5646478ef6d4a4d4
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Mar 11 17:41:28 2013 -0700

    decnet: Fix disappearing sysctl entries

    When decnet is built as a module a simple:
    echo 0.0 >/proc/sys/net/decnet/node_address

    results in most of the sysctl entries under /proc/sys/net/decnet and
    /proc/sys/net/decnet/conf disappearing.

    For more details see http://www.spinics.net/lists/netdev/msg226123.html.

    This change applies the same workaround used in
    net/core/sysctl_net_core.c and net/ipv6/sysctl_net_ipv6.c of creating
    a skeleton of decnet sysctl entries before doing anything else.

    The problem first appeared in kernel 2.6.27.  The later rewrite of
    sysctl in kernel 3.4 restored the previous behavior and eliminated the
    need for this workaround.

    This patch was heavily inspired by a similar but more complex patch by
    Larry Baker.

    Reported-by: Larry Baker <baker@usgs.gov>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Acked-by: David Miller <davem@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2fbc9de75108bba9aa8976fcf80e5bfe5283598
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Wed Feb 27 21:48:09 2013 -0500

    ftrace: Update the kconfig for DYNAMIC_FTRACE

    commit db05021d49a994ee40a9735d9c3cb0060c9babb8 upstream.

    The prompt to enable DYNAMIC_FTRACE (the ability to nop and
    enable function tracing at run time) had a confusing statement:

     "enable/disable ftrace tracepoints dynamically"

    This was written before tracepoints were added to the kernel,
    but now that tracepoints have been added, this is very confusing
    and has confused people enough to give wrong information during
    presentations.

    Not only that, I looked at the help text, and it still references
    that dreaded daemon that use to wake up once a second to update
    the nop locations and brick NICs, that hasn't been around for over
    five years.

    Time to bring the text up to the current decade.

    Reported-by: Ezequiel Garcia <elezegarcia@gmail.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb868f2c44b556ddea6a88e0a1a70945364e0ee1
Author: Tu, Xiaobing <xiaobing.tu@intel.com>
Date:   Tue Oct 23 01:03:00 2012 +0200

    Fix memory leak in cpufreq stats.

    commit e37736777254ce1abc85493a5cacbefe5983b896 upstream.

    When system enters sleep, non-boot CPUs will be disabled.
    Cpufreq stats sysfs is created when the CPU is up, but it is not
    freed when the CPU is going down. This will cause memory leak.

    Signed-off-by: xiaobing tu <xiaobing.tu@intel.com>
    Signed-off-by: guifang tang <guifang.tang@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Colin Cross <ccross@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 542e9d5675e96e3affcac837b358b6dadebbbc37
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Tue Mar 12 02:59:49 2013 +0000

    vfs: fix pipe counter breakage

    commit a930d8790552658140d7d0d2e316af4f0d76a512 upstream.

    If you open a pipe for neither read nor write, the pipe code will not
    add any usage counters to the pipe, causing the 'struct pipe_inode_info"
    to be potentially released early.

    That doesn't normally matter, since you cannot actually use the pipe,
    but the pipe release code - particularly fasync handling - still expects
    the actual pipe infrastructure to all be there.  And rather than adding
    NULL pointer checks, let's just disallow this case, the same way we
    already do for the named pipe ("fifo") case.

    This is ancient going back to pre-2.4 days, and until trinity, nobody
    naver noticed.

    Reported-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e753e515f9ee87879a0630ba71366580dd0195f
Author: David Howells <dhowells@redhat.com>
Date:   Tue Mar 12 16:44:31 2013 +1100

    keys: fix race with concurrent install_user_keyrings()

    commit 0da9dfdd2cd9889201bc6f6f43580c99165cd087 upstream.

    This fixes CVE-2013-1792.

    There is a race in install_user_keyrings() that can cause a NULL pointer
    dereference when called concurrently for the same user if the uid and
    uid-session keyrings are not yet created.  It might be possible for an
    unprivileged user to trigger this by calling keyctl() from userspace in
    parallel immediately after logging in.

    Assume that we have two threads both executing lookup_user_key(), both
    looking for KEY_SPEC_USER_SESSION_KEYRING.

    	THREAD A			THREAD B
    	===============================	===============================
    					==>call install_user_keyrings();
    	if (!cred->user->session_keyring)
    	==>call install_user_keyrings()
    					...
    					user->uid_keyring = uid_keyring;
    	if (user->uid_keyring)
    		return 0;
    	<==
    	key = cred->user->session_keyring [== NULL]
    					user->session_keyring = session_keyring;
    	atomic_inc(&key->usage); [oops]

    At the point thread A dereferences cred->user->session_keyring, thread B
    hasn't updated user->session_keyring yet, but thread A assumes it is
    populated because install_user_keyrings() returned ok.

    The race window is really small but can be exploited if, for example,
    thread B is interrupted or preempted after initializing uid_keyring, but
    before doing setting session_keyring.

    This couldn't be reproduced on a stock kernel.  However, after placing
    systemtap probe on 'user->session_keyring = session_keyring;' that
    introduced some delay, the kernel could be crashed reliably.

    Fix this by checking both pointers before deciding whether to return.
    Alternatively, the test could be done away with entirely as it is checked
    inside the mutex - but since the mutex is global, that may not be the best
    way.

    Signed-off-by: David Howells <dhowells@redhat.com>
    Reported-by: Mateusz Guzik <mguzik@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce38f02134fc8d9a43cf459a35581e046898c22b
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date:   Tue Mar 5 09:42:59 2013 +0000

    e1000e: fix pci-device enable-counter balance

    commit 4e0855dff094b0d56d6b5b271e0ce7851cc1e063 upstream.

    This patch removes redundant and unbalanced pci_disable_device() from
    __e1000_shutdown(). pci_clear_master() is enough, device can go into
    suspended state with elevated enable_cnt.

    Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
    ("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35

    Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
    Cc: Bruce Allan <bruce.w.allan@intel.com>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Tested-by: Borislav Petkov <bp@suse.de>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50a885c6f03d574acc5d88728ce5a8f4bb3df9fe
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Mar 5 15:43:39 2013 +0100

    ALSA: vmaster: Fix slave change notification

    commit 2069d483b39a603a5f3428a19d3b4ac89aa97f48 upstream.

    When a value of a vmaster slave control is changed, the ctl change
    notification is sometimes ignored.  This happens when the master
    control overrides, e.g. when the corresponding master control is
    muted.  The reason is that slave_put() returns the value of the actual
    slave put callback, and it doesn't reflect the virtual slave value
    change.

    This patch fixes the function just to return 1 whenever a slave value
    is changed.

    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30061508a22179630a1fedbb435a5cfb6d975aaa
Author: Sean Connor <sconnor004@allyinics.org>
Date:   Thu Feb 28 09:20:00 2013 -0500

    ALSA: ice1712: Initialize card->private_data properly

    commit 69a4cfdd444d1fe5c24d29b3a063964ac165d2cd upstream.

    Set card->private_data in snd_ice1712_create for fixing NULL
    dereference in snd_ice1712_remove().

    Signed-off-by: Sean Connor <sconnor004@allyinics.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98fbe03043cfc683297aa1d9787ec0e01a997cc1
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Feb 27 12:01:58 2013 -0500

    drm/radeon: add primary dac adj quirk for R200 board

    commit e8fc41377f5037ff7a661ea06adc05f1daec1548 upstream.

    vbios values are wrong leading to colors that are
    too bright.  Use the default values instead.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f7a207fa110fe9af0d8b68f243337599fb78702
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Sat Mar 2 15:33:30 2013 +0800

    hwmon: (sht15) Check return value of regulator_enable()

    commit 3e78080f81481aa8340374d5a37ae033c1cf4272 upstream.

    Not having power is a pretty serious error so check that we are able to
    enable the supply and error out if we can't.

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>

commit d726c470444d85b2cb8cf2dd87f038bb04292b00
Author: NeilBrown <neilb@suse.de>
Date:   Thu Feb 21 15:36:38 2013 +1100

    md: raid0: fix error return from create_stripe_zones.

    commit 58ebb34c49fcfcaa029e4b1c1453d92583900f9a upstream.

    Create_stripe_zones returns an error slightly differently to
    raid0_run and to raid0_takeover_*.

    The error returned used by the second was wrong and an error would
    result in mddev->private being set to NULL and sooner or later a
    crash.

    So never return NULL, return ERR_PTR(err), not NULL from
    create_stripe_zones.

    This bug has been present since 2.6.35 so the fix is suitable
    for any kernel since then.

    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b77a7b64bd40be69cf9e4476640349f9ad98fb88
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Fri Feb 22 21:09:17 2013 +0100

    ath9k: fix RSSI dummy marker value

    commit a3d63cadbad97671d740a9698acc2c95d1ca6e79 upstream.

    RSSI is being stored internally as s8 in several places. The indication
    of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been
    set to 127, but ended up being set to 0x127 because of a code cleanup
    mistake. This could lead to invalid signal strength values in a few
    places.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 728975e1e15673f9e45ee5d0f1581d8787f3c3b7
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Tue Mar 5 10:07:08 2013 +1030

    hw_random: make buffer usable in scatterlist.

    commit f7f154f1246ccc5a0a7e9ce50932627d60a0c878 upstream.

    virtio_rng feeds the randomness buffer handed by the core directly
    into the scatterlist, since commit bb347d98079a547e80bd4722dee1de61e4dca0e8.

    However, if CONFIG_HW_RANDOM=m, the static buffer isn't a linear address
    (at least on most archs).  We could fix this in virtio_rng, but it's actually
    far easier to just do it in the core as virtio_rng would have to allocate
    a buffer every time (it doesn't know how much the core will want to read).

    Reported-by: Aurelien Jarno <aurelien@aurel32.net>
    Tested-by: Aurelien Jarno <aurelien@aurel32.net>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5295f18c9d943d207fa9101b4d10952ad185b8bc
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Fri Feb 22 14:57:57 2013 -0500

    SUNRPC: Don't start the retransmission timer when out of socket space

    commit a9a6b52ee1baa865283a91eb8d443ee91adfca56 upstream.

    If the socket is full, we're better off just waiting until it empties,
    or until the connection is broken. The reason why we generally don't
    want to time out is that the call to xprt->ops->release_xprt() will
    trigger a connection reset, which isn't helpful...

    Let's make an exception for soft RPC calls, since they have to provide
    timeout guarantees.

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53c4e85f063e53ccfe9c34a78e0a33b849b37fba
Author: Jeff Layton <jlayton@redhat.com>
Date:   Fri Feb 1 15:11:01 2013 -0500

    cifs: ensure that cifs_get_root() only traverses directories

    commit ce2ac52105aa663056dfc17966ebed1bf93e6e64 upstream.

    Kjell Braden reported this oops:

    [  833.211970] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [  833.212816] IP: [<          (null)>]           (null)
    [  833.213280] PGD 1b9b2067 PUD e9f7067 PMD 0
    [  833.213874] Oops: 0010 [#1] SMP
    [  833.214344] CPU 0
    [  833.214458] Modules linked in: des_generic md4 nls_utf8 cifs vboxvideo drm snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq bnep rfcomm snd_timer bluetooth snd_seq_device ppdev snd vboxguest parport_pc joydev mac_hid soundcore snd_page_alloc psmouse i2c_piix4 serio_raw lp parport usbhid hid e1000
    [  833.215629]
    [  833.215629] Pid: 1752, comm: mount.cifs Not tainted 3.0.0-rc7-bisectcifs-fec11dd9a0+ #18 innotek GmbH VirtualBox/VirtualBox
    [  833.215629] RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
    [  833.215629] RSP: 0018:ffff8800119c9c50  EFLAGS: 00010282
    [  833.215629] RAX: ffffffffa02186c0 RBX: ffff88000c427780 RCX: 0000000000000000
    [  833.215629] RDX: 0000000000000000 RSI: ffff88000c427780 RDI: ffff88000c4362e8
    [  833.215629] RBP: ffff8800119c9c88 R08: ffff88001fc15e30 R09: 00000000d69515c7
    [  833.215629] R10: ffffffffa0201972 R11: ffff88000e8f6a28 R12: ffff88000c4362e8
    [  833.215629] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88001181aaa6
    [  833.215629] FS:  00007f2986171700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
    [  833.215629] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [  833.215629] CR2: 0000000000000000 CR3: 000000001b982000 CR4: 00000000000006f0
    [  833.215629] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  833.215629] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [  833.215629] Process mount.cifs (pid: 1752, threadinfo ffff8800119c8000, task ffff88001c1c16f0)
    [  833.215629] Stack:
    [  833.215629]  ffffffff8116a9b5 ffff8800119c9c88 ffffffff81178075 0000000000000286
    [  833.215629]  0000000000000000 ffff88000c4276c0 ffff8800119c9ce8 ffff8800119c9cc8
    [  833.215629]  ffffffff8116b06e ffff88001bc6fc00 ffff88000c4276c0 ffff88000c4276c0
    [  833.215629] Call Trace:
    [  833.215629]  [<ffffffff8116a9b5>] ? d_alloc_and_lookup+0x45/0x90
    [  833.215629]  [<ffffffff81178075>] ? d_lookup+0x35/0x60
    [  833.215629]  [<ffffffff8116b06e>] __lookup_hash.part.14+0x9e/0xc0
    [  833.215629]  [<ffffffff8116b1d6>] lookup_one_len+0x146/0x1e0
    [  833.215629]  [<ffffffff815e4f7e>] ? _raw_spin_lock+0xe/0x20
    [  833.215629]  [<ffffffffa01eef0d>] cifs_do_mount+0x26d/0x500 [cifs]
    [  833.215629]  [<ffffffff81163bd3>] mount_fs+0x43/0x1b0
    [  833.215629]  [<ffffffff8117d41a>] vfs_kern_mount+0x6a/0xd0
    [  833.215629]  [<ffffffff8117e584>] do_kern_mount+0x54/0x110
    [  833.215629]  [<ffffffff8117fdc2>] do_mount+0x262/0x840
    [  833.215629]  [<ffffffff81108a0e>] ? __get_free_pages+0xe/0x50
    [  833.215629]  [<ffffffff8117f9ca>] ? copy_mount_options+0x3a/0x180
    [  833.215629]  [<ffffffff8118075d>] sys_mount+0x8d/0xe0
    [  833.215629]  [<ffffffff815ece82>] system_call_fastpath+0x16/0x1b
    [  833.215629] Code:  Bad RIP value.
    [  833.215629] RIP  [<          (null)>]           (null)
    [  833.215629]  RSP <ffff8800119c9c50>
    [  833.215629] CR2: 0000000000000000
    [  833.238525] ---[ end trace ec00758b8d44f529 ]---

    When walking down the path on the server, it's possible to hit a
    symlink. The path walking code assumes that the caller will handle that
    situation properly, but cifs_get_root() isn't set up for it. This patch
    prevents the oops by simply returning an error.

    A better solution would be to try and chase the symlinks here, but that's
    fairly complicated to handle.

    Fixes:

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

    Reported-and-tested-by: Kjell Braden <afflux@pentabarf.de>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1244d244aea7290c80cea240baa7e5b93b439dc8
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Feb 20 14:06:20 2013 -0500

    btrfs: Init io_lock after cloning btrfs device struct

    commit 1cba0cdf5e4dbcd9e5fa5b54d7a028e55e2ca057 upstream.

    __btrfs_close_devices() clones btrfs device structs with
    memcpy(). Some of the fields in the clone are reinitialized, but it's
    missing to init io_lock. In mainline this goes unnoticed, but on RT it
    leaves the plist pointing to the original about to be freed lock
    struct.

    Initialize io_lock after cloning, so no references to the original
    struct are left.

    Reported-and-tested-by: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21a3473f1b9aaf7a458b43acb5237794e8cecadb
Author: Asias He <asias@redhat.com>
Date:   Wed Feb 27 13:29:29 2013 +0800

    target/pscsi: Fix page increment

    commit 472b72f2db7831d7dbe22ffdff4adee3bd49b05d upstream.

    The page++ is wrong. It makes bio_add_pc_page() pointing to a wrong page
    address if the 'while (len > 0 && data_len > 0) { ... }' loop is
    executed more than one once.

    Signed-off-by: Asias He <asias@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9ad62366468c20381217476c1ebc5cc13ffcbbc
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Feb 11 22:03:18 2013 +0300

    SCSI: dc395x: uninitialized variable in device_alloc()

    commit 208afec4f3be8c51ad6eebe6611dd6d2ad2fa298 upstream.

    This bug was introduced back in bitkeeper days in 2003.  We use
    "dcb->dev_mode" before it has been initialized.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b0b58069148d9540e70af1d4963b2fe515efe89
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Mon Feb 25 16:10:42 2013 +0000

    ARM: fix scheduling while atomic warning in alignment handling code

    commit b255188f90e2bade1bd11a986dd1ca4861869f4d upstream.

    Paolo Pisati reports that IPv6 triggers this warning:

    BUG: scheduling while atomic: swapper/0/0/0x40000100
    Modules linked in:
    [<c001b1c4>] (unwind_backtrace+0x0/0xf0) from [<c0503c5c>] (__schedule_bug+0x48/0x5c)
    [<c0503c5c>] (__schedule_bug+0x48/0x5c) from [<c0508608>] (__schedule+0x700/0x740)
    [<c0508608>] (__schedule+0x700/0x740) from [<c007007c>] (__cond_resched+0x24/0x34)
    [<c007007c>] (__cond_resched+0x24/0x34) from [<c05086dc>] (_cond_resched+0x3c/0x44)
    [<c05086dc>] (_cond_resched+0x3c/0x44) from [<c0021f6c>] (do_alignment+0x178/0x78c)
    [<c0021f6c>] (do_alignment+0x178/0x78c) from [<c00083e0>] (do_DataAbort+0x34/0x98)
    [<c00083e0>] (do_DataAbort+0x34/0x98) from [<c0509a60>] (__dabt_svc+0x40/0x60)
    Exception stack(0xc0763d70 to 0xc0763db8)
    3d60:                                     e97e805e e97e806e 2c000000 11000000
    3d80: ea86bb00 0000002c 00000011 e97e807e c076d2a8 e97e805e e97e806e 0000002c
    3da0: 3d000000 c0763dbc c04b98fc c02a8490 00000113 ffffffff
    [<c0509a60>] (__dabt_svc+0x40/0x60) from [<c02a8490>] (__csum_ipv6_magic+0x8/0xc8)

    Fix this by using probe_kernel_address() stead of __get_user().

    Reported-by: Paolo Pisati <p.pisati@gmail.com>
    Tested-by: Paolo Pisati <p.pisati@gmail.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95a2b9b9ce9db0856f0603f394a628e1360f79ae
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Mon Feb 25 16:09:12 2013 +0000

    ARM: VFP: fix emulation of second VFP instruction

    commit 5e4ba617c1b584b2e376f31a63bd4e734109318a upstream.

    Martin Storsjö reports that the sequence:

            ee312ac1        vsub.f32        s4, s3, s2
            ee702ac0        vsub.f32        s5, s1, s0
            e59f0028        ldr             r0, [pc, #40]
            ee111a90        vmov            r1, s3

    on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
    where s3 is a denormal and s2 is zero results in incorrect behaviour -
    the instruction "vsub.f32 s5, s1, s0" is not executed:

            VFP: bounce: trigger ee111a90 fpexc d0000780
            VFP: emulate: INST=0xee312ac1 SCR=0x00000000
            ...

    As we can see, the instruction triggering the exception is the "vmov"
    instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
    properly take account of the FPEXC_FP2V flag in FPEXC.  This is because
    the test for the second instruction register being valid is bogus, and
    will always skip emulation of the second instruction.

    Reported-by: Martin Storsjö <martin@martin.st>
    Tested-by: Martin Storsjö <martin@martin.st>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>