1. 18 12月, 2012 14 次提交
  2. 22 10月, 2012 1 次提交
    • W
      virtio: force vring descriptors to be allocated from lowmem · b92b1b89
      Will Deacon 提交于
      Virtio devices may attempt to add descriptors to a virtqueue from atomic
      context using GFP_ATOMIC allocation. This is problematic because such
      allocations can fall outside of the lowmem mapping, causing virt_to_phys
      to report bogus physical addresses which are subsequently passed to
      userspace via the buffers for the virtual device.
      
      This patch masks out __GFP_HIGH and __GFP_HIGHMEM from the requested
      flags when allocating descriptors for a virtqueue. If an atomic
      allocation is requested and later fails, we will return -ENOSPC which
      will be handled by the driver.
      
      Cc: stable@kernel.org
      Cc: Sasha Levin <levinsasha928@gmail.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      b92b1b89
  3. 16 10月, 2012 1 次提交
    • D
      thermal, cpufreq: Fix build when CPU_FREQ_TABLE isn't configured · dd8e8c4a
      David Rientjes 提交于
      Commit 02361418 ("thermal: add generic cpufreq cooling
      implementation") requires cpufreq_frequency_get_table(), but that
      function is only defined for CONFIG_CPU_FREQ_TABLE resulting in the
      following build error:
      
        drivers/built-in.o: In function `cpufreq_get_max_state':
        drivers/thermal/cpu_cooling.c:259: undefined reference to `cpufreq_frequency_get_table'
        drivers/built-in.o: In function `get_cpu_frequency':
        drivers/thermal/cpu_cooling.c:129: undefined reference to `cpufreq_frequency_get_table'
      
      Fix it by selecting CONFIG_CPU_FREQ_TABLE for such a configuration.
      
      It turns out CONFIG_EXYNOS_THERMAL also needs CONFIG_CPU_FREQ_TABLE, so
      select it there as well.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dd8e8c4a
  4. 13 10月, 2012 5 次提交
  5. 12 10月, 2012 12 次提交
  6. 11 10月, 2012 7 次提交
    • N
      md: refine reporting of resync/reshape delays. · 72f36d59
      NeilBrown 提交于
      If 'resync_max' is set to 0 (as is often done when starting a
      reshape, so the mdadm can remain in control during a sensitive
      period), and if the reshape request is initially delayed because
      another array using the same array is resyncing or reshaping etc,
      when user-space cannot easily tell when the delay changes from being
      due to a conflicting reshape, to being due to resync_max = 0.
      
      So introduce a new state: (curr_resync == 3) to reflect this, make
      sure it is visible both via /proc/mdstat and via the "sync_completed"
      sysfs attribute, and ensure that the event transition from one delay
      state to the other is properly notified.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      72f36d59
    • N
      md/raid5: be careful not to resize_stripes too big. · e56108d6
      NeilBrown 提交于
      When a RAID5 is reshaping, conf->raid_disks is increased
      before mddev->delta_disks becomes zero.
      This can result in check_reshape calling resize_stripes with a
      number that is too large.  This particularly happens
      when md_check_recovery calls ->check_reshape().
      
      If we use ->previous_raid_disks, we don't risk this.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      e56108d6
    • N
      md: make sure manual changes to recovery checkpoint are saved. · db07d85e
      NeilBrown 提交于
      If you make an array bigger but suppress resync of the new region with
        mdadm --grow /dev/mdX --size=max --assume-clean
      
      then stop the array before anything is written to it, the effect of
      the "--assume-clean" is lost and the array will resync the new space
      when restarted.
      So ensure that we update the metadata in the case.
      Reported-by: NSebastian Riemer <sebastian.riemer@profitbricks.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      db07d85e
    • D
      md/raid10: use correct limit variable · 91502f09
      Dan Carpenter 提交于
      Clang complains that we are assigning a variable to itself.  This should
      be using bad_sectors like the similar earlier check does.
      
      Bug has been present since 3.1-rc1.  It is minor but could
      conceivably cause corruption or other bad behaviour.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      91502f09
    • N
      md: writing to sync_action should clear the read-auto state. · 48c26ddc
      NeilBrown 提交于
      In some cases array are started in 'read-auto' state where in
      nothing gets written to any device until the array is written
      to.  The purpose of this is to make accidental auto-assembly
      of the wrong arrays less of a risk, and to allow arrays to be
      started to read suspend-to-disk images without actually changing
      anything (as might happen if the array were dirty and a
      resync seemed necessary).
      
      Explicitly writing the 'sync_action' for a read-auto array currently
      doesn't clear the read-auto state, so the sync action doesn't
      happen, which can be confusing.
      
      So allow any successful write to sync_action to clear any read-auto
      state.
      Reported-by: NAlexander Kühn <alexander.kuehn@nagilum.de>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      48c26ddc
    • J
      Subject: [PATCH] md:change resync_mismatches to atomic64_t to avoid races · 7f7583d4
      Jianpeng Ma 提交于
      Now that multiple threads can handle stripes, it is safer to
      use an atomic64_t for resync_mismatches, to avoid update races.
      Signed-off-by: NJianpeng Ma <majianpeng@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      7f7583d4
    • H
      e1000e: Change wthresh to 1 to avoid possible Tx stalls · 8edc0e62
      Hiroaki SHIMODA 提交于
      This patch originated from Hiroaki SHIMODA but has been modified
      by Intel with some minor cleanups and additional commit log text.
      
      Denys Fedoryshchenko and others reported Tx stalls on e1000e with
      BQL enabled.  Issue was root caused to hardware delays. They were
      introduced because some of the e1000e hardware with transmit
      writeback bursting enabled, waits until the driver does an
      explict flush OR there are WTHRESH descriptors to write back.
      
      Sometimes the delays in question were on the order of seconds,
      causing visible lag for ssh sessions and unacceptable tx
      completion latency, especially for BQL enabled kernels.
      
      To avoid possible Tx stalls, change WTHRESH back to 1.
      
      The current plan is to investigate a method for re-enabling
      WTHRESH while not harming BQL, but those patches will be later
      for net-next if they work.
      
      please enqueue for stable since v3.3 as this bug was introduced in
      commit 3f0cfa3b
      Author: Tom Herbert <therbert@google.com>
      Date:   Mon Nov 28 16:33:16 2011 +0000
      
          e1000e: Support for byte queue limits
      
          Changes to e1000e to use byte queue limits.
      Reported-by: NDenys Fedoryshchenko <denys@visp.net.lb>
      Tested-by: NDenys Fedoryshchenko <denys@visp.net.lb>
      Signed-off-by: NHiroaki SHIMODA <shimoda.hiroaki@gmail.com>
      CC: eric.dumazet@gmail.com
      CC: therbert@google.com
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8edc0e62