Revert "config: enable SELinux support"

This reverts commit f6140317c791f94af5bd5a0d7a8f2092dd76b5ee.
Revert "config: use ROW io scheduler by default"

This reverts commit 33efa6e765a367b5ab02c22c5c40f981db004cdb.
Linux 3.0.87

commit 61bfa77de71ef9d84614d3a7f0a3ca1c7af82058
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jul 21 18:15:05 2013 -0700

    Linux 3.0.87

commit 6fe0ab4d8e8b794e1d59ace3969ca8da259b25e3
Author: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date:   Wed Jul 3 15:00:43 2013 -0700

    drivers/dma/pl330.c: fix locking in pl330_free_chan_resources()

    commit da331ba8e9c5de72a27e50f71105395bba6eebe0 upstream.

    tasklet_kill() may sleep so call it before taking pch->lock.

    Fixes following lockup:

      BUG: scheduling while atomic: cat/2383/0x00000002
      Modules linked in:
        unwind_backtrace+0x0/0xfc
        __schedule_bug+0x4c/0x58
        __schedule+0x690/0x6e0
        sys_sched_yield+0x70/0x78
        tasklet_kill+0x34/0x8c
        pl330_free_chan_resources+0x24/0x88
        dma_chan_put+0x4c/0x50
      [...]
      BUG: spinlock lockup suspected on CPU#0, swapper/0/0
       lock: 0xe52aa04c, .magic: dead4ead, .owner: cat/2383, .owner_cpu: 1
        unwind_backtrace+0x0/0xfc
        do_raw_spin_lock+0x194/0x204
        _raw_spin_lock_irqsave+0x20/0x28
        pl330_tasklet+0x2c/0x5a8
        tasklet_action+0xfc/0x114
        __do_softirq+0xe4/0x19c
        irq_exit+0x98/0x9c
        handle_IPI+0x124/0x16c
        gic_handle_irq+0x64/0x68
        __irq_svc+0x40/0x70
        cpuidle_wrap_enter+0x4c/0xa0
        cpuidle_enter_state+0x18/0x68
        cpuidle_idle_call+0xac/0xe0
        cpu_idle+0xac/0xf0

    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
    Cc: Vinod Koul <vinod.koul@linux.intel.com>
    Cc: Tomasz Figa <t.figa@samsung.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 cd8bca6fe4862f5af7244a5f5e4b08788ccaff11
Author: Jed Davis <jld@mozilla.com>
Date:   Thu Jun 20 10:16:29 2013 +0100

    ARM: 7765/1: perf: Record the user-mode PC in the call chain.

    commit c5f927a6f62196226915f12194c9d0df4e2210d7 upstream.

    With this change, we no longer lose the innermost entry in the user-mode
    part of the call chain.  See also the x86 port, which includes the ip.

    It's possible to partially work around this problem by post-processing
    the data to use the PERF_SAMPLE_IP value, but this works only if the CPU
    wasn't in the kernel when the sample was taken.

    Signed-off-by: Jed Davis <jld@mozilla.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b9cf8edf9d6203e0ed7a38844f8c3c35b101a61
Author: Jan Kara <jack@suse.cz>
Date:   Fri May 31 19:39:56 2013 -0400

    ext4: fix overflow when counting used blocks on 32-bit architectures

    commit 8af8eecc1331dbf5e8c662022272cf667e213da5 upstream.

    The arithmetics adding delalloc blocks to the number of used blocks in
    ext4_getattr() can easily overflow on 32-bit archs as we first multiply
    number of blocks by blocksize and then divide back by 512. Make the
    arithmetics more clever and also use proper type (unsigned long long
    instead of unsigned long).

    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d19c4370e3e590ed083c77238866719025476108
Author: Jan Kara <jack@suse.cz>
Date:   Fri May 31 19:38:56 2013 -0400

    ext4: fix data offset overflow in ext4_xattr_fiemap() on 32-bit archs

    commit a60697f411eb365fb09e639e6f183fe33d1eb796 upstream.

    On 32-bit architectures with 32-bit sector_t computation of data offset
    in ext4_xattr_fiemap() can overflow resulting in reporting bogus data
    location. Fix the problem by typing block number to proper type before
    shifting.

    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7bcb3df9ab6ae35c239bb6fc051dd478ed47991e
Author: Bart Van Assche <bart.vanassche@gmail.com>
Date:   Tue May 21 20:43:50 2013 +0200

    timer: Fix jiffies wrap behavior of round_jiffies_common()

    commit 9e04d3804d3ac97d8c03a41d78d0f0674b5d01e1 upstream.

    Direct compare of jiffies related values does not work in the wrap
    around case. Replace it with time_is_after_jiffies().

    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Cc: Arjan van de Ven <arjan@infradead.org>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Link: http://lkml.kernel.org/r/519BC066.5080600@acm.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b53a038e4d4e68ebbee7eddbd9c8793d75c5fe3f
Author: Shane Huang <shane.huang@amd.com>
Date:   Sat Jun 8 16:00:16 2013 +0800

    ahci: remove pmp link online check in FBS EH

    commit 912b9ac683b112615d5605686f1dc086402ce9f7 upstream.

    ata_link_online() check in ahci_error_intr() is unnecessary, it should
    be removed otherwise may lead to lockup with FBS enabled PMP.
    http://marc.info/?l=linux-ide&m=137050421603272&w=2

    Reported-by: Yu Liu <liuyu.ac@gmail.com>
    Signed-off-by: Shane Huang <shane.huang@amd.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e9516f6d5f1f24e8b4f0327caf3d197400d3c1e
Author: Shane Huang <shane.huang@amd.com>
Date:   Mon Jun 3 18:24:10 2013 +0800

    ahci: Add AMD CZ SATA device ID

    commit fafe5c3d82a470d73de53e6b08eb4e28d974d895 upstream.

    To add AMD CZ SATA controller device ID of IDE mode.

    [bhelgaas: drop pci_ids.h update]
    Signed-off-by: Shane Huang <shane.huang@amd.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a32958d2ac96070c53d04bd8e013c97b260b5e6
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Wed Jul 3 15:01:03 2013 -0700

    ocfs2: xattr: fix inlined xattr reflink

    commit ef962df057aaafd714f5c22ba3de1be459571fdf upstream.

    Inlined xattr shared free space of inode block with inlined data or data
    extent record, so the size of the later two should be adjusted when
    inlined xattr is enabled.  See ocfs2_xattr_ibody_init().  But this isn't
    done well when reflink.  For inode with inlined data, its max inlined
    data size is adjusted in ocfs2_duplicate_inline_data(), no problem.  But
    for inode with data extent record, its record count isn't adjusted.  Fix
    it, or data extent record and inlined xattr may overwrite each other,
    then cause data corruption or xattr failure.

    One panic caused by this bug in our test environment is the following:

      kernel BUG at fs/ocfs2/xattr.c:1435!
      invalid opcode: 0000 [#1] SMP
      Pid: 10871, comm: multi_reflink_t Not tainted 2.6.39-300.17.1.el5uek #1
      RIP: ocfs2_xa_offset_pointer+0x17/0x20 [ocfs2]
      RSP: e02b:ffff88007a587948  EFLAGS: 00010283
      RAX: 0000000000000000 RBX: 0000000000000010 RCX: 00000000000051e4
      RDX: ffff880057092060 RSI: 0000000000000f80 RDI: ffff88007a587a68
      RBP: ffff88007a587948 R08: 00000000000062f4 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000010
      R13: ffff88007a587a68 R14: 0000000000000001 R15: ffff88007a587c68
      FS:  00007fccff7f06e0(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
      CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 00000000015cf000 CR3: 000000007aa76000 CR4: 0000000000000660
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process multi_reflink_t
      Call Trace:
        ocfs2_xa_reuse_entry+0x60/0x280 [ocfs2]
        ocfs2_xa_prepare_entry+0x17e/0x2a0 [ocfs2]
        ocfs2_xa_set+0xcc/0x250 [ocfs2]
        ocfs2_xattr_ibody_set+0x98/0x230 [ocfs2]
        __ocfs2_xattr_set_handle+0x4f/0x700 [ocfs2]
        ocfs2_xattr_set+0x6c6/0x890 [ocfs2]
        ocfs2_xattr_user_set+0x46/0x50 [ocfs2]
        generic_setxattr+0x70/0x90
        __vfs_setxattr_noperm+0x80/0x1a0
        vfs_setxattr+0xa9/0xb0
        setxattr+0xc3/0x120
        sys_fsetxattr+0xa8/0xd0
        system_call_fastpath+0x16/0x1b

    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Jie Liu <jeff.liu@oracle.com>
    Acked-by: Joel Becker <jlbec@evilplan.org>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Sunil Mushran <sunil.mushran@gmail.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 16bfeaafd474e38a6b19b2f76ef4d665f9b1b0f9
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Wed Jun 5 02:27:51 2013 +0000

    ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan

    commit eff9a4b62b14cf0d9913e3caf1f26f8b7a6105c9 upstream.

    HP Folio 13's BIOS defines CMOS RTC Operation Region and the EC's
    _REG method will access that region.  To allow the CMOS RTC region
    handler to be installed before the EC _REG method is first invoked,
    add ec_skip_dsdt_scan() as HP Folio 13's callback to ec_dmi_table.

    References: https://bugzilla.kernel.org/show_bug.cgi?id=54621
    Reported-and-tested-by: Stefan Nagy <public@stefan-nagy.at>
    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cb58457fa8a025e39363ef8496279a30c75f280
Author: Axel Lin <axel.lin@ingics.com>
Date:   Wed Jul 3 15:06:45 2013 -0700

    drivers/rtc/rtc-rv3029c2.c: fix disabling AIE irq

    commit 29ecd78c0fd6ee05f2c6b07b23823a6ae43c13ff upstream.

    In the disable AIE irq code path, current code passes "1" to enable
    parameter of rv3029c2_rtc_i2c_alarm_set_irq().  Thus it does not disable
    AIE irq.

    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Acked-by: Heiko Schocher <hs@denx.de>
    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 0b9ad5b23c1f4b9443e77c7a12f2cc5720218198
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Fri Jun 28 02:40:30 2013 +0100

    genirq: Fix can_request_irq() for IRQs without an action

    commit 2779db8d37d4b542d9ca2575f5f178dbeaca6c86 upstream.

    Commit 02725e7471b8 ('genirq: Use irq_get/put functions'),
    inadvertently changed can_request_irq() to return 0 for IRQs that have
    no action.  This causes pcibios_lookup_irq() to select only IRQs that
    already have an action with IRQF_SHARED set, or to fail if there are
    none.  Change can_request_irq() to return 1 for IRQs that have no
    action (if the first two conditions are met).

    Reported-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
    Tested-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is> (against 3.2)
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: 709647@bugs.debian.org
    Link: http://bugs.debian.org/709647
    Link: http://lkml.kernel.org/r/1372383630.23847.40.camel@deadeye.wl.decadent.org.uk
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a55f7be46db3b6cdeb23d99bbd915aa285521de2
Author: Laszlo Ersek <lersek@redhat.com>
Date:   Tue Oct 18 22:42:59 2011 +0200

    xen/time: remove blocked time accounting from xen "clockchip"

    commit 0b0c002c340e78173789f8afaa508070d838cf3d upstream.

    ... because the "clock_event_device framework" already accounts for idle
    time through the "event_handler" function pointer in
    xen_timer_interrupt().

    The patch is intended as the completion of [1]. It should fix the double
    idle times seen in PV guests' /proc/stat [2]. It should be orthogonal to
    stolen time accounting (the removed code seems to be isolated).

    The approach may be completely misguided.

    [1] https://lkml.org/lkml/2011/10/6/10
    [2] http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01068.html

    John took the time to retest this patch on top of v3.10 and reported:
    "idle time is correctly incremented for pv and hvm for the normal
    case, nohz=off and nohz=idle." so lets put this patch in.

    Signed-off-by: Laszlo Ersek <lersek@redhat.com>
    Signed-off-by: John Haxby <john.haxby@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf1febd5483958b2826de88f321df3f5856ed547
Author: Joachim Eastwood <manabian@gmail.com>
Date:   Thu Jun 6 10:24:14 2013 +0200

    pcmcia: at91_cf: fix gpio_get_value in at91_cf_get_status

    commit e39506b466edcda2a7e9d0174d7987ae654137b7 upstream.

    Commit 80af9e6d (pcmcia at91_cf: fix raw gpio number usage) forgot
    to change the parameter in gpio_get_value after adding gpio
    validation.

    Signed-off-by: Joachim Eastwood <manabian@gmail.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 281eb7655ac766335f8fe47da6695e538dc063df
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Jun 17 09:56:33 2013 -0700

    xhci: check for failed dma pool allocation

    commit 025f880cb2e4d7218d0422d4b07bea1a68959c38 upstream.

    Fail and free the container context in case dma_pool_alloc() can't allocate
    the raw context data part of it

    This patch should be backported to kernels as old as 2.6.31, that
    contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 "USB: xhci:
    Support for 64-byte contexts".

    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: John Youn <johnyoun@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fad6ba80759e3efa6e0a7a1463cf3e506f53b85f
Author: UCHINO Satoshi <satoshi.uchino@toshiba.co.jp>
Date:   Thu May 23 11:10:11 2013 +0900

    usb: gadget: f_mass_storage: add missing memory barrier for thread_wakeup_needed

    commit d68c277b501889b3a50c179d1c3d704db7947b83 upstream.

    Without this memory barrier, the file-storage thread may fail to
    escape from the following while loop, because it may observe new
    common->thread_wakeup_needed and old bh->state which are updated by
    the callback functions.

        /* Wait for the CBW to arrive */
        while (bh->state != BUF_STATE_FULL) {
            rc = sleep_thread(common);
            if (rc)
                return rc;
        }

    Signed-off-by: UCHINO Satoshi <satoshi.uchino@toshiba.co.jp>
    Acked-by: Michal Nazarewicz <mina86@mina86.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a5152cd2778b10414d2184b6d31c71a1e068e97
Author: Dan Williams <dcbw@redhat.com>
Date:   Thu Jun 20 16:07:40 2013 -0500

    USB: option,qcserial: move Novatel Gobi1K IDs to qcserial

    commit a254810a86aaaac4ac6ba44fa934558b042a17a7 upstream.

    These devices are all Gobi1K devices (according to the Windows INF
    files) and should be handled by qcserial instead of option.  Their
    network port is handled by qmi_wwan.

    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 791750989d8eba46434f2c0b02154ace47be6c8e
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Mon Jul 1 08:12:38 2013 -0400

    ext3,ext4: don't mess with dir_file->f_pos in htree_dirblock_to_tree()

    commit 64cb927371cd2ec43758d8a094a003d27bc3d0dc upstream.

    Both ext3 and ext4 htree_dirblock_to_tree() is just filling the
    in-core rbtree for use by call_filldir().  All updates of ->f_pos are
    done by the latter; bumping it here (on error) is obviously wrong - we
    might very well have it nowhere near the block we'd found an error in.

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23643c00e5d692fa53fc7630931e6694b02f27ef
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Mon Jul 1 08:12:40 2013 -0400

    jbd2: fix theoretical race in jbd2__journal_restart

    commit 39c04153fda8c32e85b51c96eb5511a326ad7609 upstream.

    Once we decrement transaction->t_updates, if this is the last handle
    holding the transaction from closing, and once we release the
    t_handle_lock spinlock, it's possible for the transaction to commit
    and be released.  In practice with normal kernels, this probably won't
    happen, since the commit happens in a separate kernel thread and it's
    unlikely this could all happen within the space of a few CPU cycles.

    On the other hand, with a real-time kernel, this could potentially
    happen, so save the tid found in transaction->t_tid before we release
    t_handle_lock.  It would require an insane configuration, such as one
    where the jbd2 thread was set to a very high real-time priority,
    perhaps because a high priority real-time thread is trying to read or
    write to a file system.  But some people who use real-time kernels
    have been known to do insane things, including controlling
    laser-wielding industrial robots.  :-)

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge branch 'cm-10.1-wip' of git://github.com/Mustaavalkosta/htc7x30-3.0 into rs-dev
netfilter: xt_qtaguid: fix error exit that would keep a spinlock.

qtudev_open() could return with a uid_tag_data_tree_lock held
when an kzalloc(..., GFP_ATOMIC) would fail.
Very unlikely to get triggered AND survive the mayhem of running out of mem.

Signed-off-by: JP Abgrall <jpa@google.com>
netfilter: qtaguid: Don't BUG_ON if create_if_tag_stat fails

If create_if_tag_stat fails to allocate memory (GFP_ATOMIC) the
following will happen:

qtaguid: iface_stat: tag stat alloc failed
...
kernel BUG at xt_qtaguid.c:1482!

Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
netfilter: xt_qtaguid: remove AID_* dependency for access control

qtaguid limits what can be done with /ctrl and /stats based on group
membership.
This changes removes AID_NET_BW_STATS and AID_NET_BW_ACCT, and picks
up the groups from the gid of the matching proc entry files.

Signed-off-by: JP Abgrall <jpa@google.com>
Change-Id: I42e477adde78a12ed5eb58fbc0b277cdaadb6f94
netfilter: xt_qtaguid: extend iface stat to report protocols

In the past the iface_stat_fmt would only show global bytes/packets
for the skb-based numbers.
For stall detection in userspace, distinguishing tcp vs other protocols
makes it easier.
Now we report
  ifname total_skb_rx_bytes total_skb_rx_packets total_skb_tx_bytes
  total_skb_tx_packets {rx,tx}_{tcp,udp,ohter}_{bytes,packets}

Bug: 6818637
Signed-off-by: JP Abgrall <jpa@google.com>
Change-Id: I179c5ebf2fe822acec0bce4973b4bbb5e7d5076d
netfilter: xt_qtaguid: Allow tracking loopback

In the past it would always ignore interfaces with loopback addresses.
Now we just treat them like any other.
This also helps with writing tests that check for the presence
of the qtaguid module.

Signed-off-by: JP Abgrall <jpa@google.com>
Merge branch 'cm-10.1-wip' of git://github.com/Mustaavalkosta/htc7x30-3.0 into rs-dev
tick: Prevent uncontrolled switch to oneshot mode

commit 1f73a9806bdd07a5106409bbcab3884078bd34fe upstream.

When the system switches from periodic to oneshot mode, the broadcast
logic causes a possibility that a CPU which has not yet switched to
oneshot mode puts its own clock event device into oneshot mode without
updating the state and the timer handler.

CPU0				CPU1
				per cpu tickdev is in periodic mode
				and switched to broadcast

Switch to oneshot mode
 tick_broadcast_switch_to_oneshot()
  cpumask_copy(tick_oneshot_broacast_mask,
	       tick_broadcast_mask);

  broadcast device mode = oneshot

				Timer interrupt

				irq_enter()
				 tick_check_oneshot_broadcast()
				  dev->set_mode(ONESHOT);

				tick_handle_periodic()
				 if (dev->mode == ONESHOT)
				   dev->next_event += period;
				   FAIL.

We fail, because dev->next_event contains KTIME_MAX, if the device was
in periodic mode before the uncontrolled switch to oneshot happened.

We must copy the broadcast bits over to the oneshot mask, because
otherwise a CPU which relies on the broadcast would not been woken up
anymore after the broadcast device switched to oneshot mode.

So we need to verify in tick_check_oneshot_broadcast() whether the CPU
has already switched to oneshot mode. If not, leave the device
untouched and let the CPU switch controlled into oneshot mode.

This is a long standing bug, which was never noticed, because the main
user of the broadcast x86 cannot run into that scenario, AFAICT. The
nonarchitected timer mess of ARM creates a gazillion of differently
broken abominations which trigger the shortcomings of that broadcast
code, which better had never been necessary in the first place.

Reported-and-tested-by: Stehle Vincent-B46079 <B46079@freescale.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Cc: John Stultz <john.stultz@linaro.org>,
Cc: Mark Rutland <mark.rutland@arm.com>
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1307012153060.4013@ionos.tec.linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ASoC: sglt5000: Fix SGTL5000_PLL_FRAC_DIV_MASK

commit 5c78dfe87ea04b501ee000a7f03b9432ac9d008c upstream.

SGTL5000_PLL_FRAC_DIV_MASK is used to mask bits 0-10 (11 bits in total) of
register CHIP_PLL_CTRL, so fix the mask to accomodate all this bit range.

Reported-by: Oskar Schirmer <oskar@scara.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rt2x00: read 5GHz TX power values from the correct offset

commit 0a6f3a8ebaf13407523c2c7d575b4ca2debd23ba upstream.

The current code uses the same index value both
for the channel information array and for the TX
power table. The index starts from 14, however the
index of the TX power table must start from zero.

Fix it, in order to get the correct TX power value
for a given channel.

The changes in rt61pci.c and rt73usb.c are compile
tested only.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SCSI: zfcp: fix adapter (re)open recovery while link to SAN is down

commit f76ccaac4f82c463a037aa4a1e4ccb85c7011814 upstream.

FCP device remains in status ERP_FAILED when device is switched online
or adapter recovery is triggered  while link to SAN is down.

When Exchange Configuration Data command returns the FSF status
FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE it aborts the exchange process.
The only retries are done during the common error recovery procedure
(i.e. max. 3 retries with 8sec sleep between) and remains in status
ERP_FAILED with QDIO down.

This commit reverts the commit 0df138476c8306478d6e726f044868b4bccf411c
(zfcp: Fix adapter activation on link down).
When FSF status FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE is received the
adapter recovery will be finished without any retries. QDIO will be
up now and status changes such as LINK UP will be received now.

Signed-off-by: Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SCSI: mpt2sas: fix firmware failure with wrong task attribute

commit 48ba2efc382f94fae16ca8ca011e5961a81ad1ea upstream.

When SCSI command is received with task attribute not set, set it to SIMPLE.
Previously it is set to untagged. This causes the firmware to fail the commands.

Signed-off-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tracing: Use current_uid() for critical time tracing

commit f17a5194859a82afe4164e938b92035b86c55794 upstream.

The irqsoff tracer records the max time that interrupts are disabled.
There are hooks in the assembly code that calls back into the tracer when
interrupts are disabled or enabled.

When they are enabled, the tracer checks if the amount of time they
were disabled is larger than the previous recorded max interrupts off
time. If it is, it creates a snapshot of the currently running trace
to store where the last largest interrupts off time was held and how
it happened.

During testing, this RCU lockdep dump appeared:

[ 1257.829021] ===============================
[ 1257.829021] [ INFO: suspicious RCU usage. ]
[ 1257.829021] 3.10.0-rc1-test+ #171 Tainted: G        W
[ 1257.829021] -------------------------------
[ 1257.829021] /home/rostedt/work/git/linux-trace.git/include/linux/rcupdate.h:780 rcu_read_lock() used illegally while idle!
[ 1257.829021]
[ 1257.829021] other info that might help us debug this:
[ 1257.829021]
[ 1257.829021]
[ 1257.829021] RCU used illegally from idle CPU!
[ 1257.829021] rcu_scheduler_active = 1, debug_locks = 0
[ 1257.829021] RCU used illegally from extended quiescent state!
[ 1257.829021] 2 locks held by trace-cmd/4831:
[ 1257.829021]  #0:  (max_trace_lock){......}, at: [<ffffffff810e2b77>] stop_critical_timing+0x1a3/0x209
[ 1257.829021]  #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff810dae5a>] __update_max_tr+0x88/0x1ee
[ 1257.829021]
[ 1257.829021] stack backtrace:
[ 1257.829021] CPU: 3 PID: 4831 Comm: trace-cmd Tainted: G        W    3.10.0-rc1-test+ #171
[ 1257.829021] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
[ 1257.829021]  0000000000000001 ffff880065f49da8 ffffffff8153dd2b ffff880065f49dd8
[ 1257.829021]  ffffffff81092a00 ffff88006bd78680 ffff88007add7500 0000000000000003
[ 1257.829021]  ffff88006bd78680 ffff880065f49e18 ffffffff810daebf ffffffff810dae5a
[ 1257.829021] Call Trace:
[ 1257.829021]  [<ffffffff8153dd2b>] dump_stack+0x19/0x1b
[ 1257.829021]  [<ffffffff81092a00>] lockdep_rcu_suspicious+0x109/0x112
[ 1257.829021]  [<ffffffff810daebf>] __update_max_tr+0xed/0x1ee
[ 1257.829021]  [<ffffffff810dae5a>] ? __update_max_tr+0x88/0x1ee
[ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
[ 1257.829021]  [<ffffffff810dbf85>] update_max_tr_single+0x11d/0x12d
[ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
[ 1257.829021]  [<ffffffff810e2b15>] stop_critical_timing+0x141/0x209
[ 1257.829021]  [<ffffffff8109569a>] ? trace_hardirqs_on+0xd/0xf
[ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
[ 1257.829021]  [<ffffffff810e3057>] time_hardirqs_on+0x2a/0x2f
[ 1257.829021]  [<ffffffff811002b9>] ? user_enter+0xfd/0x107
[ 1257.829021]  [<ffffffff8109550c>] trace_hardirqs_on_caller+0x16/0x197
[ 1257.829021]  [<ffffffff8109569a>] trace_hardirqs_on+0xd/0xf
[ 1257.829021]  [<ffffffff811002b9>] user_enter+0xfd/0x107
[ 1257.829021]  [<ffffffff810029b4>] do_notify_resume+0x92/0x97
[ 1257.829021]  [<ffffffff8154bdca>] int_signal+0x12/0x17

What happened was entering into the user code, the interrupts were enabled
and a max interrupts off was recorded. The trace buffer was saved along with
various information about the task: comm, pid, uid, priority, etc.

The uid is recorded with task_uid(tsk). But this is a macro that uses rcu_read_lock()
to retrieve the data, and this happened to happen where RCU is blind (user_enter).

As only the preempt and irqs off tracers can have this happen, and they both
only have the tsk == current, if tsk == current, use current_uid() instead of
task_uid(), as current_uid() does not use RCU as only current can change its uid.

This fixes the RCU suspicious splat.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perf: Clone child context from parent context pmu

commit 734df5ab549ca44f40de0f07af1c8803856dfb18 upstream.

Currently when the child context for inherited events is
created, it's based on the pmu object of the first event
of the parent context.

This is wrong for the following scenario:

  - HW context having HW and SW event
  - HW event got removed (closed)
  - SW event stays in HW context as the only event
    and its pmu is used to clone the child context

The issue starts when the cpu context object is touched
based on the pmu context object (__get_cpu_context). In
this case the HW context will work with SW cpu context
ending up with following WARN below.

Fixing this by using parent context pmu object to clone
from child context.

Addresses the following warning reported by Vince Weaver:

[ 2716.472065] ------------[ cut here ]------------
[ 2716.476035] WARNING: at kernel/events/core.c:2122 task_ctx_sched_out+0x3c/0x)
[ 2716.476035] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs locn
[ 2716.476035] CPU: 0 PID: 3164 Comm: perf_fuzzer Not tainted 3.10.0-rc4 #2
[ 2716.476035] Hardware name: AOpen   DE7000/nMCP7ALPx-DE R1.06 Oct.19.2012, BI2
[ 2716.476035]  0000000000000000 ffffffff8102e215 0000000000000000 ffff88011fc18
[ 2716.476035]  ffff8801175557f0 0000000000000000 ffff880119fda88c ffffffff810ad
[ 2716.476035]  ffff880119fda880 ffffffff810af02a 0000000000000009 ffff880117550
[ 2716.476035] Call Trace:
[ 2716.476035]  [<ffffffff8102e215>] ? warn_slowpath_common+0x5b/0x70
[ 2716.476035]  [<ffffffff810ab2bd>] ? task_ctx_sched_out+0x3c/0x5f
[ 2716.476035]  [<ffffffff810af02a>] ? perf_event_exit_task+0xbf/0x194
[ 2716.476035]  [<ffffffff81032a37>] ? do_exit+0x3e7/0x90c
[ 2716.476035]  [<ffffffff810cd5ab>] ? __do_fault+0x359/0x394
[ 2716.476035]  [<ffffffff81032fe6>] ? do_group_exit+0x66/0x98
[ 2716.476035]  [<ffffffff8103dbcd>] ? get_signal_to_deliver+0x479/0x4ad
[ 2716.476035]  [<ffffffff810ac05c>] ? __perf_event_task_sched_out+0x230/0x2d1
[ 2716.476035]  [<ffffffff8100205d>] ? do_signal+0x3c/0x432
[ 2716.476035]  [<ffffffff810abbf9>] ? ctx_sched_in+0x43/0x141
[ 2716.476035]  [<ffffffff810ac2ca>] ? perf_event_context_sched_in+0x7a/0x90
[ 2716.476035]  [<ffffffff810ac311>] ? __perf_event_task_sched_in+0x31/0x118
[ 2716.476035]  [<ffffffff81050dd9>] ? mmdrop+0xd/0x1c
[ 2716.476035]  [<ffffffff81051a39>] ? finish_task_switch+0x7d/0xa6
[ 2716.476035]  [<ffffffff81002473>] ? do_notify_resume+0x20/0x5d
[ 2716.476035]  [<ffffffff813654f5>] ? retint_signal+0x3d/0x78
[ 2716.476035] ---[ end trace 827178d8a5966c3d ]---

Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1373384651-6109-1-git-send-email-jolsa@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perf: Remove WARN_ON_ONCE() check in __perf_event_enable() for valid scenario

commit 06f417968beac6e6b614e17b37d347aa6a6b1d30 upstream.

The '!ctx->is_active' check has a valid scenario, so
there's no need for the warning.

The reason is that there's a time window between the
'ctx->is_active' check in the perf_event_enable() function
and the __perf_event_enable() function having:

  - IRQs on
  - ctx->lock unlocked

where the task could be killed and 'ctx' deactivated by
perf_event_exit_task(), ending up with the warning below.

So remove the WARN_ON_ONCE() check and add comments to
explain it all.

This addresses the following warning reported by Vince Weaver:

[  324.983534] ------------[ cut here ]------------
[  324.984420] WARNING: at kernel/events/core.c:1953 __perf_event_enable+0x187/0x190()
[  324.984420] Modules linked in:
[  324.984420] CPU: 19 PID: 2715 Comm: nmi_bug_snb Not tainted 3.10.0+ #246
[  324.984420] Hardware name: Supermicro X8DTN/X8DTN, BIOS 4.6.3 01/08/2010
[  324.984420]  0000000000000009 ffff88043fce3ec8 ffffffff8160ea0b ffff88043fce3f00
[  324.984420]  ffffffff81080ff0 ffff8802314fdc00 ffff880231a8f800 ffff88043fcf7860
[  324.984420]  0000000000000286 ffff880231a8f800 ffff88043fce3f10 ffffffff8108103a
[  324.984420] Call Trace:
[  324.984420]  <IRQ>  [<ffffffff8160ea0b>] dump_stack+0x19/0x1b
[  324.984420]  [<ffffffff81080ff0>] warn_slowpath_common+0x70/0xa0
[  324.984420]  [<ffffffff8108103a>] warn_slowpath_null+0x1a/0x20
[  324.984420]  [<ffffffff81134437>] __perf_event_enable+0x187/0x190
[  324.984420]  [<ffffffff81130030>] remote_function+0x40/0x50
[  324.984420]  [<ffffffff810e51de>] generic_smp_call_function_single_interrupt+0xbe/0x130
[  324.984420]  [<ffffffff81066a47>] smp_call_function_single_interrupt+0x27/0x40
[  324.984420]  [<ffffffff8161fd2f>] call_function_single_interrupt+0x6f/0x80
[  324.984420]  <EOI>  [<ffffffff816161a1>] ? _raw_spin_unlock_irqrestore+0x41/0x70
[  324.984420]  [<ffffffff8113799d>] perf_event_exit_task+0x14d/0x210
[  324.984420]  [<ffffffff810acd04>] ? switch_task_namespaces+0x24/0x60
[  324.984420]  [<ffffffff81086946>] do_exit+0x2b6/0xa40
[  324.984420]  [<ffffffff8161615c>] ? _raw_spin_unlock_irq+0x2c/0x30
[  324.984420]  [<ffffffff81087279>] do_group_exit+0x49/0xc0
[  324.984420]  [<ffffffff81096854>] get_signal_to_deliver+0x254/0x620
[  324.984420]  [<ffffffff81043057>] do_signal+0x57/0x5a0
[  324.984420]  [<ffffffff8161a164>] ? __do_page_fault+0x2a4/0x4e0
[  324.984420]  [<ffffffff8161665c>] ? retint_restore_args+0xe/0xe
[  324.984420]  [<ffffffff816166cd>] ? retint_signal+0x11/0x84
[  324.984420]  [<ffffffff81043605>] do_notify_resume+0x65/0x80
[  324.984420]  [<ffffffff81616702>] retint_signal+0x46/0x84
[  324.984420] ---[ end trace 442ec2f04db3771a ]---

Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Suggested-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1373384651-6109-2-git-send-email-jolsa@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perf: Fix perf_lock_task_context() vs RCU

commit 058ebd0eba3aff16b144eabf4510ed9510e1416e upstream.

Jiri managed to trigger this warning:

 [] ======================================================
 [] [ INFO: possible circular locking dependency detected ]
 [] 3.10.0+ #228 Tainted: G        W
 [] -------------------------------------------------------
 [] p/6613 is trying to acquire lock:
 []  (rcu_node_0){..-...}, at: [<ffffffff810ca797>] rcu_read_unlock_special+0xa7/0x250
 []
 [] but task is already holding lock:
 []  (&ctx->lock){-.-...}, at: [<ffffffff810f2879>] perf_lock_task_context+0xd9/0x2c0
 []
 [] which lock already depends on the new lock.
 []
 [] the existing dependency chain (in reverse order) is:
 []
 [] -> #4 (&ctx->lock){-.-...}:
 [] -> #3 (&rq->lock){-.-.-.}:
 [] -> #2 (&p->pi_lock){-.-.-.}:
 [] -> #1 (&rnp->nocb_gp_wq[1]){......}:
 [] -> #0 (rcu_node_0){..-...}:

Paul was quick to explain that due to preemptible RCU we cannot call
rcu_read_unlock() while holding scheduler (or nested) locks when part
of the read side critical section was preemptible.

Therefore solve it by making the entire RCU read side non-preemptible.

Also pull out the retry from under the non-preempt to play nice with RT.

Reported-by: Jiri Olsa <jolsa@redhat.com>
Helped-out-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sparc32: vm_area_struct access for old Sun SPARCs.

upstream commit 961246b4ed8da3bcf4ee1eb9147f341013553e3c

Commit e4c6bfd2d79d063017ab19a18915f0bc759f32d9 ("mm: rearrange
vm_area_struct for fewer cache misses") changed the layout of the
vm_area_struct structure, it broke several SPARC32 assembly routines
which used numerical constants for accessing the vm_mm field.

This patch defines the VMA_VM_MM constant to replace the immediate values.

Signed-off-by: Olivier DANET <odanet@caramail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>