1. 15 Jan, 2015 40 commits
    • Paul Mackerras's avatar
      powerpc/powernv: Switch off MMU before entering nap/sleep/rvwinkle mode · e7c25b93
      Paul Mackerras authored
      commit 8117ac6a upstream.
      
      Currently, when going idle, we set the flag indicating that we are in
      nap mode (paca->kvm_hstate.hwthread_state) and then execute the nap
      (or sleep or rvwinkle) instruction, all with the MMU on.  This is bad
      for two reasons: (a) the architecture specifies that those instructions
      must be executed with the MMU off, and in fact with only the SF, HV, ME
      and possibly RI bits set, and (b) this introduces a race, because as
      soon as we set the flag, another thread can switch the MMU to a guest
      context.  If the race is lost, this thread will typically start looping
      on relocation-on ISIs at 0xc...4400.
      
      This fixes it by setting the MSR as required by the architecture before
      setting the flag or executing the nap/sleep/rvwinkle instruction.
      
      [ shreyas@linux.vnet.ibm.com: Edited to handle LE ]
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarShreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e7c25b93
    • Thomas Gleixner's avatar
      genirq: Prevent proc race against freeing of irq descriptors · 5e95fa4f
      Thomas Gleixner authored
      commit c291ee62 upstream.
      
      Since the rework of the sparse interrupt code to actually free the
      unused interrupt descriptors there exists a race between the /proc
      interfaces to the irq subsystem and the code which frees the interrupt
      descriptor.
      
      CPU0				CPU1
      				show_interrupts()
      				  desc = irq_to_desc(X);
      free_desc(desc)
        remove_from_radix_tree();
        kfree(desc);
      				  raw_spinlock_irq(&desc->lock);
      
      /proc/interrupts is the only interface which can actively corrupt
      kernel memory via the lock access. /proc/stat can only read from freed
      memory. Extremly hard to trigger, but possible.
      
      The interfaces in /proc/irq/N/ are not affected by this because the
      removal of the proc file is serialized in procfs against concurrent
      readers/writers. The removal happens before the descriptor is freed.
      
      For architectures which have CONFIG_SPARSE_IRQ=n this is a non issue
      as the descriptor is never freed. It's merely cleared out with the irq
      descriptor lock held. So any concurrent proc access will either see
      the old correct value or the cleared out ones.
      
      Protect the lookup and access to the irq descriptor in
      show_interrupts() with the sparse_irq_lock.
      
      Provide kstat_irqs_usr() which is protecting the lookup and access
      with sparse_irq_lock and switch /proc/stat to use it.
      
      Document the existing kstat_irqs interfaces so it's clear that the
      caller needs to take care about protection. The users of these
      interfaces are either not affected due to SPARSE_IRQ=n or already
      protected against removal.
      
      Fixes: 1f5a5b87 "genirq: Implement a sane sparse_irq allocator"
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5e95fa4f
    • Sagi Grimberg's avatar
      iscsi,iser-target: Expose supported protection ops according to t10_pi · 0f990013
      Sagi Grimberg authored
      commit 23a548ee upstream.
      
      iSER will report supported protection operations based on
      the tpg attribute t10_pi settings and HCA PI offload capabilities.
      If the HCA does not support PI offload or tpg attribute t10_pi is
      not set, we fall to SW PI mode.
      
      In order to do that, we move iscsit_get_sup_prot_ops after connection
      tpg assignment.
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0f990013
    • Sagi Grimberg's avatar
      iser-target: Fix NULL dereference in SW mode DIF · c52c1599
      Sagi Grimberg authored
      commit 302cc7c3 upstream.
      
      Fallback to software mode DIF if HCA does not support
      PI (without crashing obviously). It is still possible to
      run with backend protection and an unprotected frontend,
      so looking at the command prot_op is not enough. Check
      device PI capability on a per-IO basis (isert_prot_cmd
      inline static) to determine if we need to handle protection
      information.
      
      Trace:
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      IP: [<ffffffffa037f8b1>] isert_reg_sig_mr+0x351/0x3b0 [ib_isert]
      Call Trace:
       [<ffffffff812b003a>] ? swiotlb_map_sg_attrs+0x7a/0x130
       [<ffffffffa038184d>] isert_reg_rdma+0x2fd/0x370 [ib_isert]
       [<ffffffff8108f2ec>] ? idle_balance+0x6c/0x2c0
       [<ffffffffa0382b68>] isert_put_datain+0x68/0x210 [ib_isert]
       [<ffffffffa02acf5b>] lio_queue_data_in+0x2b/0x30 [iscsi_target_mod]
       [<ffffffffa02306eb>] target_complete_ok_work+0x21b/0x310 [target_core_mod]
       [<ffffffff8106ece2>] process_one_work+0x182/0x3b0
       [<ffffffff8106fda0>] worker_thread+0x120/0x3c0
       [<ffffffff8106fc80>] ? maybe_create_worker+0x190/0x190
       [<ffffffff8107594e>] kthread+0xce/0xf0
       [<ffffffff81075880>] ? kthread_freezable_should_stop+0x70/0x70
       [<ffffffff8159a22c>] ret_from_fork+0x7c/0xb0
       [<ffffffff81075880>] ? kthread_freezable_should_stop+0x70/0x70
      Reported-by: default avatarSlava Shwartsman <valyushash@gmail.com>
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c52c1599
    • Sagi Grimberg's avatar
      iser-target: Allocate PI contexts dynamically · 2a9a256d
      Sagi Grimberg authored
      commit 570db170 upstream.
      
      This patch converts to allocate PI contexts dynamically in order
      avoid a potentially bogus np->tpg_np and associated NULL pointer
      dereference in isert_connect_request() during iser-target endpoint
      shutdown with multiple network portals.
      
      Also, there is really no need to allocate these at connection
      establishment since it is not guaranteed that all the IOs on
      that connection will be to a PI formatted device.
      
      We can do it in a lazy fashion so the initial burst will have a
      transient slow down, but very fast all IOs will allocate a PI
      context.
      
      Squashed:
      
      iser-target: Centralize PI context handling code
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2a9a256d
    • Sagi Grimberg's avatar
      iser-target: Fix implicit termination of connections · 63dff7ee
      Sagi Grimberg authored
      commit b02efbfc upstream.
      
      In situations such as bond failover, The new session establishment
      implicitly invokes the termination of the old connection.
      
      So, we don't want to wait for the old connection wait_conn to completely
      terminate before we accept the new connection and post a login response.
      
      The solution is to deffer the comp_wait completion and the conn_put to
      a work so wait_conn will effectively be non-blocking (flush errors are
      assumed to come very fast).
      
      We allocate isert_release_wq with WQ_UNBOUND and WQ_UNBOUND_MAX_ACTIVE
      to spread the concurrency of release works.
      Reported-by: default avatarSlava Shwartsman <valyushash@gmail.com>
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      63dff7ee
    • Sagi Grimberg's avatar
      iser-target: Handle ADDR_CHANGE event for listener cm_id · 868d84f1
      Sagi Grimberg authored
      commit ca6c1d82 upstream.
      
      The np listener cm_id will also get ADDR_CHANGE event
      upcall (in case it is bound to a specific IP). Handle
      it correctly by creating a new cm_id and implicitly
      destroy the old one.
      
      Since this is the second event a listener np cm_id may
      encounter, we move the np cm_id event handling to a
      routine.
      
      Squashed:
      
      iser-target: Move cma_id setup to a function
      Reported-by: default avatarSlava Shwartsman <valyushash@gmail.com>
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      868d84f1
    • Sagi Grimberg's avatar
      iser-target: Fix connected_handler + teardown flow race · d1bfea1a
      Sagi Grimberg authored
      commit 19e2090f upstream.
      
      Take isert_conn pointer from cm_id->qp->qp_context. This
      will allow us to know that the cm_id context is always
      the network portal. This will make the cm_id event check
      (connection or network portal) more reliable.
      
      In order to avoid a NULL dereference in cma_id->qp->qp_context
      we destroy the qp after we destroy the cm_id (and make the
      dereference safe). session stablishment/teardown sequences
      can happen in parallel, we should take into account that
      connected_handler might race with connection teardown flow.
      
      Also, protect isert_conn->conn_device->active_qps decrement
      within the error patch during QP creation failure and the
      normal teardown path in isert_connect_release().
      
      Squashed:
      
      iser-target: Decrement completion context active_qps in error flow
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d1bfea1a
    • Sagi Grimberg's avatar
      iser-target: Parallelize CM connection establishment · 611bb15b
      Sagi Grimberg authored
      commit 2371e5da upstream.
      
      There is no point in accepting a new CM request only
      when we are completely done with the last iscsi login.
      Instead we accept immediately, this will also cause the
      CM connection to reach connected state and the initiator
      is allowed to send the first login. We mark that we got
      the initial login and let iscsi layer pick it up when it
      gets there.
      
      This reduces the parallel login sequence by a factor of
      more then 4 (and more for multi-login) and also prevents
      the initiator (who does all logins in parallel) from
      giving up on login timeout expiration.
      
      In order to support multiple login requests sequence (CHAP)
      we call isert_rx_login_req from isert_rx_completion insead
      of letting isert_get_login_rx call it.
      
      Squashed:
      
      iser-target: Use kref_get_unless_zero in connected_handler
      iser-target: Acquire conn_mutex when changing connection state
      iser-target: Reject connect request in failure path
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      611bb15b
    • Sagi Grimberg's avatar
      iser-target: Fix flush + disconnect completion handling · 170b761c
      Sagi Grimberg authored
      commit 128e9cc8 upstream.
      
      ISER_CONN_UP state is not sufficient to know if
      we should wait for completion of flush errors and
      disconnected_handler event.
      
      Instead, split it to 2 states:
      - ISER_CONN_UP: Got to CM connected phase, This state
      indicates that we need to wait for a CM disconnect
      event before going to teardown.
      
      - ISER_CONN_FULL_FEATURE: Got to full feature phase
      after we posted login response, This state indicates
      that we posted recv buffers and we need to wait for
      flush completions before going to teardown.
      
      Also avoid deffering disconnected handler to a work,
      and handle it within disconnected handler.
      More work here is needed to handle DEVICE_REMOVAL event
      correctly (cleanup all resources).
      
      Squashed:
      
      iser-target: Don't deffer disconnected handler to a work
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      170b761c
    • Sagi Grimberg's avatar
      iscsi,iser-target: Initiate termination only once · 96b50563
      Sagi Grimberg authored
      commit 954f2372 upstream.
      
      Since commit 0fc4ea70 ("Target/iser: Don't put isert_conn inside
      disconnected handler") we put the conn kref in isert_wait_conn, so we
      need .wait_conn to be invoked also in the error path.
      
      Introduce call to isert_conn_terminate (called under lock)
      which transitions the connection state to TERMINATING and calls
      rdma_disconnect. If the state is already teminating, just bail
      out back (temination started).
      
      Also, make sure to destroy the connection when getting a connect
      error event if didn't get to connected (state UP). Same for the
      handling of REJECTED and UNREACHABLE cma events.
      
      Squashed:
      
      iscsi-target: Add call to wait_conn in establishment error flow
      Reported-by: default avatarSlava Shwartsman <valyushash@gmail.com>
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      96b50563
    • Imre Deak's avatar
      drm/i915: vlv: fix IRQ masking when uninstalling interrupts · 1eadc8e9
      Imre Deak authored
      commit c352d1ba upstream.
      
      irq_mask should include all IRQ bits that we want to mask, but atm we
      set it incorrectly to the inverse of this. If the mask is used
      subsequently to enable/disable some IRQ bits, we may unintentionally
      unmask unrelated IRQs. I can't see any way that this can lead to a real
      problem in the current -nightly code, since the first place the mask
      will be used next (after a suspend/resume cycle) is in
      valleyview_irq_postinstall(), but the mask is reset there to its proper
      value.
      
      This causes a problem in the upstream kernel though, where - due to another
      issue - the mask is used in the above way to disable only the display IRQs.
      This other issue is fixed by:
      
      commit 950eabaf
      Author: Imre Deak <imre.deak@intel.com>
      Date:   Mon Sep 8 15:21:09 2014 +0300
      
          drm/i915: vlv: fix display IRQ enable/disable
      
      Interestingly, even with the above two bugs, we shouldn't in theory have
      any real problems (arguably a famous last sentence:). That's because
      even if we unmask something unintentionally via the VLV_IMR/VLV_IER
      register the master IRQ masking bit in VLV_MASTER_IER is still set and
      should prevent all i915 interrupts. According to my testing on an ASUS
      T100 with DSI output this isn't the case at least with the
      MIPIA_INTERRUPT. Leaving this one unmasked in IMR/IER, while having
      VLV_MASTER_IER set to 0 may lead to a lockup during system suspend as
      shown in the bugzilla ticket below. This fix should get rid of the
      problem reported there in upstream and older kernels.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85920Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1eadc8e9
    • Jiri Olsa's avatar
      perf: Fix events installation during moving group · 4b64cc90
      Jiri Olsa authored
      commit 9fc81d87 upstream.
      
      We allow PMU driver to change the cpu on which the event
      should be installed to. This happened in patch:
      
        e2d37cd2 ("perf: Allow the PMU driver to choose the CPU on which to install events")
      
      This patch also forces all the group members to follow
      the currently opened events cpu if the group happened
      to be moved.
      
      This and the change of event->cpu in perf_install_in_context()
      function introduced in:
      
        0cda4c02 ("perf: Introduce perf_pmu_migrate_context()")
      
      forces group members to change their event->cpu,
      if the currently-opened-event's PMU changed the cpu
      and there is a group move.
      
      Above behaviour causes problem for breakpoint events,
      which uses event->cpu to touch cpu specific data for
      breakpoints accounting. By changing event->cpu, some
      breakpoints slots were wrongly accounted for given
      cpu.
      
      Vinces's perf fuzzer hit this issue and caused following
      WARN on my setup:
      
         WARNING: CPU: 0 PID: 20214 at arch/x86/kernel/hw_breakpoint.c:119 arch_install_hw_breakpoint+0x142/0x150()
         Can't find any breakpoint slot
         [...]
      
      This patch changes the group moving code to keep the event's
      original cpu.
      Reported-by: default avatarVince Weaver <vince@deater.net>
      Signed-off-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vince Weaver <vince@deater.net>
      Cc: Yan, Zheng <zheng.z.yan@intel.com>
      Link: http://lkml.kernel.org/r/1418243031-20367-3-git-send-email-jolsa@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4b64cc90
    • Jiri Olsa's avatar
      perf/x86/intel/uncore: Make sure only uncore events are collected · bf4f2373
      Jiri Olsa authored
      commit af91568e upstream.
      
      The uncore_collect_events functions assumes that event group
      might contain only uncore events which is wrong, because it
      might contain any type of events.
      
      This bug leads to uncore framework touching 'not' uncore events,
      which could end up all sorts of bugs.
      
      One was triggered by Vince's perf fuzzer, when the uncore code
      touched breakpoint event private event space as if it was uncore
      event and caused BUG:
      
         BUG: unable to handle kernel paging request at ffffffff82822068
         IP: [<ffffffff81020338>] uncore_assign_events+0x188/0x250
         ...
      
      The code in uncore_assign_events() function was looking for
      event->hw.idx data while the event was initialized as a
      breakpoint with different members in event->hw union.
      
      This patch forces uncore_collect_events() to collect only uncore
      events.
      Reported-by: default avatarVince Weaver <vince@deater.net>
      Signed-off-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Yan, Zheng <zheng.z.yan@intel.com>
      Link: http://lkml.kernel.org/r/1418243031-20367-2-git-send-email-jolsa@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bf4f2373
    • Filipe Manana's avatar
      Btrfs: fix fs corruption on transaction abort if device supports discard · a20425e3
      Filipe Manana authored
      commit 678886bd upstream.
      
      When we abort a transaction we iterate over all the ranges marked as dirty
      in fs_info->freed_extents[0] and fs_info->freed_extents[1], clear them
      from those trees, add them back (unpin) to the free space caches and, if
      the fs was mounted with "-o discard", perform a discard on those regions.
      Also, after adding the regions to the free space caches, a fitrim ioctl call
      can see those ranges in a block group's free space cache and perform a discard
      on the ranges, so the same issue can happen without "-o discard" as well.
      
      This causes corruption, affecting one or multiple btree nodes (in the worst
      case leaving the fs unmountable) because some of those ranges (the ones in
      the fs_info->pinned_extents tree) correspond to btree nodes/leafs that are
      referred by the last committed super block - breaking the rule that anything
      that was committed by a transaction is untouched until the next transaction
      commits successfully.
      
      I ran into this while running in a loop (for several hours) the fstest that
      I recently submitted:
      
        [PATCH] fstests: add btrfs test to stress chunk allocation/removal and fstrim
      
      The corruption always happened when a transaction aborted and then fsck complained
      like this:
      
         _check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
         *** fsck.btrfs output ***
         Check tree block failed, want=94945280, have=0
         Check tree block failed, want=94945280, have=0
         Check tree block failed, want=94945280, have=0
         Check tree block failed, want=94945280, have=0
         Check tree block failed, want=94945280, have=0
         read block failed check_tree_block
         Couldn't open file system
      
      In this case 94945280 corresponded to the root of a tree.
      Using frace what I observed was the following sequence of steps happened:
      
         1) transaction N started, fs_info->pinned_extents pointed to
            fs_info->freed_extents[0];
      
         2) node/eb 94945280 is created;
      
         3) eb is persisted to disk;
      
         4) transaction N commit starts, fs_info->pinned_extents now points to
            fs_info->freed_extents[1], and transaction N completes;
      
         5) transaction N + 1 starts;
      
         6) eb is COWed, and btrfs_free_tree_block() called for this eb;
      
         7) eb range (94945280 to 94945280 + 16Kb) is added to
            fs_info->pinned_extents (fs_info->freed_extents[1]);
      
         8) Something goes wrong in transaction N + 1, like hitting ENOSPC
            for example, and the transaction is aborted, turning the fs into
            readonly mode. The stack trace I got for example:
      
            [112065.253935]  [<ffffffff8140c7b6>] dump_stack+0x4d/0x66
            [112065.254271]  [<ffffffff81042984>] warn_slowpath_common+0x7f/0x98
            [112065.254567]  [<ffffffffa0325990>] ? __btrfs_abort_transaction+0x50/0x10b [btrfs]
            [112065.261674]  [<ffffffff810429e5>] warn_slowpath_fmt+0x48/0x50
            [112065.261922]  [<ffffffffa032949e>] ? btrfs_free_path+0x26/0x29 [btrfs]
            [112065.262211]  [<ffffffffa0325990>] __btrfs_abort_transaction+0x50/0x10b [btrfs]
            [112065.262545]  [<ffffffffa036b1d6>] btrfs_remove_chunk+0x537/0x58b [btrfs]
            [112065.262771]  [<ffffffffa033840f>] btrfs_delete_unused_bgs+0x1de/0x21b [btrfs]
            [112065.263105]  [<ffffffffa0343106>] cleaner_kthread+0x100/0x12f [btrfs]
            (...)
            [112065.264493] ---[ end trace dd7903a975a31a08 ]---
            [112065.264673] BTRFS: error (device sdc) in btrfs_remove_chunk:2625: errno=-28 No space left
            [112065.264997] BTRFS info (device sdc): forced readonly
      
         9) The clear kthread sees that the BTRFS_FS_STATE_ERROR bit is set in
            fs_info->fs_state and calls btrfs_cleanup_transaction(), which in
            turn calls btrfs_destroy_pinned_extent();
      
         10) Then btrfs_destroy_pinned_extent() iterates over all the ranges
             marked as dirty in fs_info->freed_extents[], and for each one
             it calls discard, if the fs was mounted with "-o discard", and
             adds the range to the free space cache of the respective block
             group;
      
         11) btrfs_trim_block_group(), invoked from the fitrim ioctl code path,
             sees the free space entries and performs a discard;
      
         12) After an umount and mount (or fsck), our eb's location on disk was full
             of zeroes, and it should have been untouched, because it was marked as
             dirty in the fs_info->pinned_extents tree, and therefore used by the
             trees that the last committed superblock points to.
      
      Fix this by not performing a discard and not adding the ranges to the free space
      caches - it's useless from this point since the fs is now in readonly mode and
      we won't write free space caches to disk anymore (otherwise we would leak space)
      nor any new superblock. By not adding the ranges to the free space caches, it
      prevents other code paths from allocating that space and write to it as well,
      therefore being safer and simpler.
      
      This isn't a new problem, as it's been present since 2011 (git commit
      acce952b).
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a20425e3
    • Peter Rosin's avatar
      ASoC: pcm512x: Trigger auto-increment of register addresses on i2c · c28dedb1
      Peter Rosin authored
      commit 681a1956 upstream.
      
      When the codec is connected using i2c, it will only auto-increment
      register addresses if msb (0x80) of the register address byte is set.
      
      [Fixes cache sync if multiple adjacent registers are updated -- broonie]
      Signed-off-by: default avatarPeter Rosin <peda@axentia.se>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c28dedb1
    • Sreekanth Reddy's avatar
      Revert "[SCSI] mpt3sas: Remove phys on topology change" · 8e2d7c21
      Sreekanth Reddy authored
      commit 2311ce4d upstream.
      
      This reverts commit 963ba22b
      ("mpt3sas: Remove phys on topology change")
      
      Reverting the previous mpt3sas drives patch changes,
      since we will observe below issue
      
      Issue:
      Drives connected Enclosure/Expander will unregister with
      SCSI Transport Layer, if any one remove and add expander
      cable with in DMD (Device Missing Delay) time period or
      even any one power-off and power-on the Enclosure with in
      the DMD period.
      Signed-off-by: default avatarSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
      Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8e2d7c21
    • Sreekanth Reddy's avatar
      Revert "[SCSI] mpt2sas: Remove phys on topology change." · f3263457
      Sreekanth Reddy authored
      commit 81a89c2d upstream.
      
      This reverts commit 3520f9c7
      ("mpt2sas: Remove phys on topology change")
      
      Reverting the previous mpt2sas drives patch changes,
      since we will observe below issue
      
      Issue:
      Drives connected Enclosure/Expander will unregister with
      SCSI Transport Layer, if any one remove and add expander
      cable with in DMD (Device Missing Delay) time period or
      even any one power-off and power-on the Enclosure with in
      the DMD period.
      Signed-off-by: default avatarSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
      Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f3263457
    • Krzysztof Kozlowski's avatar
      clk: samsung: Fix double add of syscore ops after driver rebind · 495548a3
      Krzysztof Kozlowski authored
      commit c31844ff upstream.
      
      During driver unbind the syscore ops were not unregistered which lead to
      double add on syscore list:
      
      $ echo "3810000.audss-clock-controller" > /sys/bus/platform/drivers/exynos-audss-clk/unbind
      $ echo "3810000.audss-clock-controller" > /sys/bus/platform/drivers/exynos-audss-clk/bind
      [ 1463.044061] ------------[ cut here ]------------
      [ 1463.047255] WARNING: CPU: 0 PID: 1 at lib/list_debug.c:36 __list_add+0x8c/0xc0()
      [ 1463.054613] list_add double add: new=c06e52c0, prev=c06e52c0, next=c06d5f84.
      [ 1463.061625] Modules linked in:
      [ 1463.064623] CPU: 0 PID: 1 Comm: bash Tainted: G        W      3.18.0-rc5-next-20141121-00005-ga8fab06eab42-dirty #1022
      [ 1463.075338] [<c0014e2c>] (unwind_backtrace) from [<c0011d80>] (show_stack+0x10/0x14)
      [ 1463.083046] [<c0011d80>] (show_stack) from [<c048bb70>] (dump_stack+0x70/0xbc)
      [ 1463.090236] [<c048bb70>] (dump_stack) from [<c00233d4>] (warn_slowpath_common+0x74/0xb0)
      [ 1463.098295] [<c00233d4>] (warn_slowpath_common) from [<c00234a4>] (warn_slowpath_fmt+0x30/0x40)
      [ 1463.106962] [<c00234a4>] (warn_slowpath_fmt) from [<c020fe80>] (__list_add+0x8c/0xc0)
      [ 1463.114760] [<c020fe80>] (__list_add) from [<c0282094>] (register_syscore_ops+0x30/0x3c)
      [ 1463.122819] [<c0282094>] (register_syscore_ops) from [<c0392f20>] (exynos_audss_clk_probe+0x36c/0x460)
      [ 1463.132091] [<c0392f20>] (exynos_audss_clk_probe) from [<c0283084>] (platform_drv_probe+0x48/0xa4)
      [ 1463.141013] [<c0283084>] (platform_drv_probe) from [<c0281a14>] (driver_probe_device+0x13c/0x37c)
      [ 1463.149852] [<c0281a14>] (driver_probe_device) from [<c0280560>] (bind_store+0x90/0xe0)
      [ 1463.157822] [<c0280560>] (bind_store) from [<c027fd10>] (drv_attr_store+0x20/0x2c)
      [ 1463.165363] [<c027fd10>] (drv_attr_store) from [<c0143898>] (sysfs_kf_write+0x4c/0x50)
      [ 1463.173252] [<c0143898>] (sysfs_kf_write) from [<c0142c80>] (kernfs_fop_write+0xbc/0x198)
      [ 1463.181395] [<c0142c80>] (kernfs_fop_write) from [<c00e2be0>] (vfs_write+0xa0/0x1a8)
      [ 1463.189104] [<c00e2be0>] (vfs_write) from [<c00e2f00>] (SyS_write+0x40/0x8c)
      [ 1463.196122] [<c00e2f00>] (SyS_write) from [<c000f2a0>] (ret_fast_syscall+0x0/0x48)
      [ 1463.203655] ---[ end trace 08f6710c9bc8d8f3 ]---
      [ 1463.208244] exynos-audss-clk 3810000.audss-clock-controller: setup completed
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: 1241ef94 ("clk: samsung: register audio subsystem clocks using common clock framework")
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      495548a3
    • Hannes Reinecke's avatar
      tcm_loop: Fix wrong I_T nexus association · ceae09be
      Hannes Reinecke authored
      commit 506787a2 upstream.
      
      tcm_loop has the I_T nexus associated with the HBA. This causes
      commands to become misdirected if the HBA has more than one
      target portal group; any command is then being sent to the
      first target portal group instead of the correct one.
      
      The nexus needs to be associated with the target portal group
      instead.
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ceae09be
    • Michael Halcrow's avatar
      eCryptfs: Remove buggy and unnecessary write in file name decode routine · ea447345
      Michael Halcrow authored
      commit 94208064 upstream.
      
      Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the
      end of the allocated buffer during encrypted filename decoding. This
      fix corrects the issue by getting rid of the unnecessary 0 write when
      the current bit offset is 2.
      Signed-off-by: default avatarMichael Halcrow <mhalcrow@google.com>
      Reported-by: default avatarDmitry Chernenkov <dmitryc@google.com>
      Suggested-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ea447345
    • Tyler Hicks's avatar
      eCryptfs: Force RO mount when encrypted view is enabled · 52676ee1
      Tyler Hicks authored
      commit 332b122d upstream.
      
      The ecryptfs_encrypted_view mount option greatly changes the
      functionality of an eCryptfs mount. Instead of encrypting and decrypting
      lower files, it provides a unified view of the encrypted files in the
      lower filesystem. The presence of the ecryptfs_encrypted_view mount
      option is intended to force a read-only mount and modifying files is not
      supported when the feature is in use. See the following commit for more
      information:
      
        e77a56dd [PATCH] eCryptfs: Encrypted passthrough
      
      This patch forces the mount to be read-only when the
      ecryptfs_encrypted_view mount option is specified by setting the
      MS_RDONLY flag on the superblock. Additionally, this patch removes some
      broken logic in ecryptfs_open() that attempted to prevent modifications
      of files when the encrypted view feature was in use. The check in
      ecryptfs_open() was not sufficient to prevent file modifications using
      system calls that do not operate on a file descriptor.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Reported-by: default avatarPriya Bansal <p.bansal@samsung.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      52676ee1
    • Uwe Kleine-König's avatar
      ARM: mvebu: fix ordering in Armada 370 .dtsi · 201bf1ab
      Uwe Kleine-König authored
      commit ab1e8537 upstream.
      
      Commit a095b1c7 ("ARM: mvebu: sort DT nodes by address")
      missed placing the system-controller in the correct order.
      
      Fixes: a095b1c7 ("ARM: mvebu: sort DT nodes by address")
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Acked-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lkml.kernel.org/r/20141114204333.GS27002@pengutronix.deSigned-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      201bf1ab
    • Mikulas Patocka's avatar
      dm thin: fix a race in thin_dtr · ec08e40b
      Mikulas Patocka authored
      commit 17181fb7 upstream.
      
      As long as struct thin_c is in the list, anyone can grab a reference of
      it.  Consequently, we must wait for the reference count to drop to zero
      *after* we remove the structure from the list, not before.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ec08e40b
    • Dan Carpenter's avatar
      dm space map metadata: fix sm_bootstrap_get_nr_blocks() · 09b8f31f
      Dan Carpenter authored
      commit c1c6156f upstream.
      
      This function isn't right and it causes a static checker warning:
      
      	drivers/md/dm-thin.c:3016 maybe_resize_data_dev()
      	error: potentially using uninitialized 'sb_data_size'.
      
      It should set "*count" and return zero on success the same as the
      sm_metadata_get_nr_blocks() function does earlier.
      
      Fixes: 3241b1d3 ('dm: add persistent data library')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      09b8f31f
    • Peter Guo's avatar
      mmc: sdhci-pci-o2micro: Fix Dell E5440 issue · 500c7483
      Peter Guo authored
      commit 6380ea09 upstream.
      
      Fix Dell E5440 when reboot Linux, can't find o2micro sd host chip issue.
      
      Fixes: 01acf691 (mmc: sdhci-pci: add support of O2Micro/BayHubTech SD hosts)
      Signed-off-by: default avatarPeter Guo <peter.guo@bayhubtech.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      500c7483
    • Ulf Hansson's avatar
      mmc: omap_hsmmc: Fix UHS card with DDR50 support · fef97029
      Ulf Hansson authored
      commit 903101a8 upstream.
      
      The commit, mmc: omap: clarify DDR timing mode between SD-UHS and eMMC,
      switched omap_hsmmc to support MMC DDR mode instead of UHS DDR50 mode.
      
      Add UHS DDR50 mode again and this time let's also keep the MMC DDR mode.
      
      Fixes: 5438ad95 (mmc: omap: clarify DDR timing mode between SD-UHS and eMMC)
      Reported-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      fef97029
    • Baruch Siach's avatar
      mmc: block: add newline to sysfs display of force_ro · 30f6a604
      Baruch Siach authored
      commit 0031a98a upstream.
      
      Make force_ro consistent with other sysfs entries.
      
      Fixes: 371a689f ('mmc: MMC boot partitions support')
      Cc: Andrei Warkentin <andrey.warkentin@gmail.com>
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      30f6a604
    • NeilBrown's avatar
      md/bitmap: always wait for writes on unplug. · 9c0bc567
      NeilBrown authored
      commit 4b5060dd upstream.
      
      If two threads call bitmap_unplug at the same time, then
      one might schedule all the writes, and the other might
      decide that it doesn't need to wait.  But really it does.
      
      It rarely hurts to wait when it isn't absolutely necessary,
      and the current code doesn't really focus on 'absolutely necessary'
      anyway.  So just wait always.
      
      This can potentially lead to data corruption if a crash happens
      at an awkward time and data was written before the bitmap was
      updated.  It is very unlikely, but this should go to -stable
      just to be safe.  Appropriate for any -stable.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9c0bc567
    • Junxiao Bi's avatar
      ocfs2: fix journal commit deadlock · dedddea7
      Junxiao Bi authored
      commit 136f49b9 upstream.
      
      For buffer write, page lock will be got in write_begin and released in
      write_end, in ocfs2_write_end_nolock(), before it unlock the page in
      ocfs2_free_write_ctxt(), it calls ocfs2_run_deallocs(), this will ask
      for the read lock of journal->j_trans_barrier.  Holding page lock and
      ask for journal->j_trans_barrier breaks the locking order.
      
      This will cause a deadlock with journal commit threads, ocfs2cmt will
      get write lock of journal->j_trans_barrier first, then it wakes up
      kjournald2 to do the commit work, at last it waits until done.  To
      commit journal, kjournald2 needs flushing data first, it needs get the
      cache page lock.
      
      Since some ocfs2 cluster locks are holding by write process, this
      deadlock may hung the whole cluster.
      
      unlock pages before ocfs2_run_deallocs() can fix the locking order, also
      put unlock before ocfs2_commit_trans() to make page lock is unlocked
      before j_trans_barrier to preserve unlocking order.
      Signed-off-by: default avatarJunxiao Bi <junxiao.bi@oracle.com>
      Reviewed-by: default avatarWengang Wang <wen.gang.wang@oracle.com>
      Reviewed-by: default avatarMark Fasheh <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      dedddea7
    • Eric W. Biederman's avatar
      mnt: Fix a memory stomp in umount · 87b431a6
      Eric W. Biederman authored
      commit c297abfd upstream.
      
      While reviewing the code of umount_tree I realized that when we append
      to a preexisting unmounted list we do not change pprev of the former
      first item in the list.
      
      Which means later in namespace_unlock hlist_del_init(&mnt->mnt_hash) on
      the former first item of the list will stomp unmounted.first leaving
      it set to some random mount point which we are likely to free soon.
      
      This isn't likely to hit, but if it does I don't know how anyone could
      track it down.
      
      [ This happened because we don't have all the same operations for
        hlist's as we do for normal doubly-linked lists. In particular,
        list_splice() is easy on our standard doubly-linked lists, while
        hlist_splice() doesn't exist and needs both start/end entries of the
        hlist.  And commit 38129a13 incorrectly open-coded that missing
        hlist_splice().
      
        We should think about making these kinds of "mindless" conversions
        easier to get right by adding the missing hlist helpers   - Linus ]
      
      Fixes: 38129a13 switch mnt_hash to hlist
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      87b431a6
    • Dan Carpenter's avatar
      ceph: do_sync is never initialized · 75398b8a
      Dan Carpenter authored
      commit 021b77be upstream.
      
      Probably this code was syncing a lot more often then intended because
      the do_sync variable wasn't set to zero.
      
      Fixes: c62988ec ('ceph: avoid meaningless calling ceph_caps_revoking if sync_mode == WB_SYNC_ALL.')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      75398b8a
    • Johannes Berg's avatar
      mac80211: free management frame keys when removing station · 8a0de588
      Johannes Berg authored
      commit 28a9bc68 upstream.
      
      When writing the code to allow per-station GTKs, I neglected to
      take into account the management frame keys (index 4 and 5) when
      freeing the station and only added code to free the first four
      data frame keys.
      
      Fix this by iterating the array of keys over the right length.
      
      Fixes: e31b8213 ("cfg80211/mac80211: allow per-station GTKs")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8a0de588
    • Jan Kara's avatar
      isofs: Fix infinite looping over CE entries · 56221faf
      Jan Kara authored
      commit f54e18f1 upstream.
      
      Rock Ridge extensions define so called Continuation Entries (CE) which
      define where is further space with Rock Ridge data. Corrupted isofs
      image can contain arbitrarily long chain of these, including a one
      containing loop and thus causing kernel to end in an infinite loop when
      traversing these entries.
      
      Limit the traversal to 32 entries which should be more than enough space
      to store all the Rock Ridge data.
      Reported-by: default avatarP J P <ppandit@redhat.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      56221faf
    • Vineet Gupta's avatar
      ARC: [nsimosci] move peripherals to match model to FPGA · a52d27cc
      Vineet Gupta authored
      commit e8ef060b upstream.
      
      This allows the sdplite/Zebu images to run on OSCI simulation platform
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a52d27cc
    • Andy Lutomirski's avatar
      x86/tls: Disallow unusual TLS segments · 2686d2b3
      Andy Lutomirski authored
      commit 0e58af4e upstream.
      
      Users have no business installing custom code segments into the
      GDT, and segments that are not present but are otherwise valid
      are a historical source of interesting attacks.
      
      For completeness, block attempts to set the L bit.  (Prior to
      this patch, the L bit would have been silently dropped.)
      
      This is an ABI break.  I've checked glibc, musl, and Wine, and
      none of them look like they'll have any trouble.
      
      Note to stable maintainers: this is a hardening patch that fixes
      no known bugs.  Given the possibility of ABI issues, this
      probably shouldn't be backported quickly.
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: security@kernel.org <security@kernel.org>
      Cc: Willy Tarreau <w@1wt.eu>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2686d2b3
    • Andy Lutomirski's avatar
      x86/tls: Validate TLS entries to protect espfix · 339ee067
      Andy Lutomirski authored
      commit 41bdc785 upstream.
      
      Installing a 16-bit RW data segment into the GDT defeats espfix.
      AFAICT this will not affect glibc, Wine, or dosemu at all.
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: security@kernel.org <security@kernel.org>
      Cc: Willy Tarreau <w@1wt.eu>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      339ee067
    • Steven Rostedt (Red Hat)'s avatar
      tracing/sched: Check preempt_count() for current when reading task->state · 41cab775
      Steven Rostedt (Red Hat) authored
      commit aee4e5f3 upstream.
      
      When recording the state of a task for the sched_switch tracepoint a check of
      task_preempt_count() is performed to see if PREEMPT_ACTIVE is set. This is
      because, technically, a task being preempted is really in the TASK_RUNNING
      state, and that is what should be recorded when tracing a sched_switch,
      even if the task put itself into another state (it hasn't scheduled out
      in that state yet).
      
      But with the change to use per_cpu preempt counts, the
      task_thread_info(p)->preempt_count is no longer used, and instead
      task_preempt_count(p) is used.
      
      The problem is that this does not use the current preempt count but a stale
      one from a previous sched_switch. The task_preempt_count(p) uses
      saved_preempt_count and not preempt_count(). But for tracing sched_switch,
      if p is current, we really want preempt_count().
      
      I hit this bug when I was tracing sleep and the call from do_nanosleep()
      scheduled out in the "RUNNING" state.
      
                 sleep-4290  [000] 537272.259992: sched_switch:         sleep:4290 [120] R ==> swapper/0:0 [120]
                 sleep-4290  [000] 537272.260015: kernel_stack:         <stack trace>
      => __schedule (ffffffff8150864a)
      => schedule (ffffffff815089f8)
      => do_nanosleep (ffffffff8150b76c)
      => hrtimer_nanosleep (ffffffff8108d66b)
      => SyS_nanosleep (ffffffff8108d750)
      => return_to_handler (ffffffff8150e8e5)
      => tracesys_phase2 (ffffffff8150c844)
      
      After a bit of hair pulling, I found that the state was really
      TASK_INTERRUPTIBLE, but the saved_preempt_count had an old PREEMPT_ACTIVE
      set and caused the sched_switch tracepoint to show it as RUNNING.
      
      Link: http://lkml.kernel.org/r/20141210174428.3cb7542a@gandalf.local.homeAcked-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: 01028747 "sched: Create more preempt_count accessors"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      41cab775
    • Brian Norris's avatar
      mtd: tests: abort torturetest on erase errors · 53f4c937
      Brian Norris authored
      commit 68f29815 upstream.
      
      The torture test should quit once it actually induces an error in the
      flash. This step was accidentally removed during refactoring.
      
      Without this fix, the torturetest just continues infinitely, or until
      the maximum cycle count is reached. e.g.:
      
         ...
         [ 7619.218171] mtd_test: error -5 while erasing EB 100
         [ 7619.297981] mtd_test: error -5 while erasing EB 100
         [ 7619.377953] mtd_test: error -5 while erasing EB 100
         [ 7619.457998] mtd_test: error -5 while erasing EB 100
         [ 7619.537990] mtd_test: error -5 while erasing EB 100
         ...
      
      Fixes: 6cf78358 ("mtd: mtd_torturetest: use mtd_test helpers")
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Cc: Akinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      53f4c937
    • Jiri Slaby's avatar
      reiserfs: destroy allocated commit workqueue · f8546f79
      Jiri Slaby authored
      commit fa0c5540 upstream.
      
      When resirefs is trying to mount a partition, it creates a commit
      workqueue (sbi->commit_wq). But when mount fails later, the workqueue
      is not freed.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Reported-by: auxsvr@gmail.com
      Reported-by: default avatarBenoît Monin <benoit.monin@gmx.fr>
      Cc: Jan Kara <jack@suse.cz>
      Cc: reiserfs-devel@vger.kernel.org
      Fixes: 797d9016Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f8546f79