1. 21 1月, 2014 11 次提交
  2. 20 1月, 2014 1 次提交
  3. 19 1月, 2014 1 次提交
  4. 18 1月, 2014 1 次提交
  5. 17 1月, 2014 1 次提交
    • M
      e1000e: Fix compilation warning when !CONFIG_PM_SLEEP · 38a529b5
      Mika Westerberg 提交于
      Commit 7509963c (e1000e: Fix a compile flag mis-match for
      suspend/resume) moved suspend and resume hooks to be available when
      CONFIG_PM is set. However, it can be set even if CONFIG_PM_SLEEP is not set
      causing following warnings to be emitted:
      
      drivers/net/ethernet/intel/e1000e/netdev.c:6178:12: warning:
        	‘e1000_suspend’ defined but not used [-Wunused-function]
      
      drivers/net/ethernet/intel/e1000e/netdev.c:6185:12: warning:
      	‘e1000_resume’ defined but not used [-Wunused-function]
      
      To fix this make the hooks to be available only when CONFIG_PM_SLEEP is set
      and remove CONFIG_PM wrapping from driver ops because this is already
      handled by SET_SYSTEM_SLEEP_PM_OPS() and SET_RUNTIME_PM_OPS().
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Dave Ertman <davidx.m.ertman@intel.com>
      Cc: Aaron Brown <aaron.f.brown@intel.com>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38a529b5
  6. 16 1月, 2014 4 次提交
  7. 15 1月, 2014 12 次提交
  8. 14 1月, 2014 9 次提交
    • E
      s390/qdio: bridgeport support - CHSC part · 1c59a861
      Eugene Crosser 提交于
      Introduce function for the "Perform network-subchannel operation"
      CHSC command with operation code "bridgeport information",
      and bit definitions for "characteristics" pertaning to this command.
      Signed-off-by: NEugene Crosser <eugene.crosser@ru.ibm.com>
      Reviewed-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      1c59a861
    • B
      net: usbnet: fix SG initialisation · fdc3452c
      Bjørn Mork 提交于
      Commit 60e453a9 ("USBNET: fix handling padding packet")
      added an extra SG entry in case padding is necessary, but
      failed to update the initialisation of the list. This can
      cause list traversal to fall off the end of the list,
      resulting in an oops.
      
      Fixes: 60e453a9 ("USBNET: fix handling padding packet")
      Reported-by: NThomas Kear <thomas@kear.co.nz>
      Cc: Ming Lei <ming.lei@canonical.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Tested-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fdc3452c
    • N
      md: fix problem when adding device to read-only array with bitmap. · 8313b8e5
      NeilBrown 提交于
      If an array is started degraded, and then the missing device
      is found it can be re-added and a minimal bitmap-based recovery
      will bring it fully up-to-date.
      
      If the array is read-only a recovery would not be allowed.
      But also if the array is read-only and the missing device was
      present very recently, then there could be no need for any
      recovery at all, so we simply include the device in the read-only
      array without any recovery.
      
      However... if the missing device was removed a little longer ago
      it could be missing some updates, but if a bitmap is present it will
      be conditionally accepted pending a bitmap-based update.  We don't
      currently detect this case properly and will include that old
      device into the read-only array with no recovery even though it really
      needs a recovery.
      
      This patch keeps track of whether a bitmap-based-recovery is really
      needed or not in the new Bitmap_sync rdev flag.  If that is set,
      then the device will not be added to a read-only array.
      
      Cc: Andrei Warkentin <andreiw@vmware.com>
      Fixes: d70ed2e4
      Cc: stable@vger.kernel.org (3.2+)
      Signed-off-by: NNeilBrown <neilb@suse.de>
      8313b8e5
    • N
      md/raid10: fix bug when raid10 recovery fails to recover a block. · e8b84915
      NeilBrown 提交于
      commit e875ecea
          md/raid10 record bad blocks as needed during recovery.
      
      added code to the "cannot recover this block" path to record a bad
      block rather than fail the whole recovery.
      Unfortunately this new case was placed *after* r10bio was freed rather
      than *before*, yet it still uses r10bio.
      This is will crash with a null dereference.
      
      So move the freeing of r10bio down where it is safe.
      
      Cc: stable@vger.kernel.org (v3.1+)
      Fixes: e875eceaReported-by: NDamian Nowak <spam@nowaker.net>
      URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181Signed-off-by: NNeilBrown <neilb@suse.de>
      e8b84915
    • N
      md/raid5: fix a recently broken BUG_ON(). · 5af9bef7
      NeilBrown 提交于
      commit 6d183de4
          md/raid5: fix newly-broken locking in get_active_stripe.
      
      simplified a BUG_ON, but removed too much so now it sometimes fires
      when it shouldn't.
      
      When the STRIPE_EXPANDING flag is set, the stripe_head might be on a
      special list while multiple stripe_heads are collected, or it might
      not be on any list, even a 'free' list when the refcount is zero.  As
      long as STRIPE_EXPANDING is set, it will be found and added back to a
      list eventually.
      
      So both of the BUG_ONs which test for the ->lru being empty or not
      need to avoid the case where STRIPE_EXPANDING is set.
      
      The patch which broke this was marked for -stable, so this patch needs
      to be applied to any branch that received 6d183de4
      
      Fixes: 6d183de4
      Cc: stable@vger.kernel.org (any release to which above was applied)
      Signed-off-by: NNeilBrown <neilb@suse.de>
      5af9bef7
    • N
      md/raid1: fix request counting bug in new 'barrier' code. · 41a336e0
      NeilBrown 提交于
      The new iobarrier implementation in raid1 (which keeps normal writes
      and resync activity separate) counts every request what is not before
      the current resync point in either next_window_requests or
      current_window_requests.
      It flags that the request is counted by setting ->start_next_window.
      
      allow_barrier follows this model exactly and decrements one of the
      *_window_requests if and only if ->start_next_window is set.
      
      However wait_barrier(), which increments *_window_requests uses a
      slightly different test for setting -.start_next_window (which is set
      from the return value of this function).
      So there is a possibility of the counts getting out of sync, and this
      leads to the resync hanging.
      
      So change wait_barrier() to return a non-zero value in exactly the
      same cases that it increments *_window_requests.
      
      But was introduced in 3.13-rc1.
      Reported-by: NBruno Wolff III <bruno@wolff.to>
      URL: https://bugzilla.kernel.org/show_bug.cgi?id=68061
      Fixes: 79ef3a8a
      Cc: majianpeng <majianpeng@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      41a336e0
    • N
      md/raid10: fix two bugs in handling of known-bad-blocks. · b50c259e
      NeilBrown 提交于
      If we discover a bad block when reading we split the request and
      potentially read some of it from a different device.
      
      The code path of this has two bugs in RAID10.
      1/ we get a spin_lock with _irq, but unlock without _irq!!
      2/ The calculation of 'sectors_handled' is wrong, as can be clearly
         seen by comparison with raid1.c
      
      This leads to at least 2 warnings and a probable crash is a RAID10
      ever had known bad blocks.
      
      Cc: stable@vger.kernel.org (v3.1+)
      Fixes: 856e08e2Reported-by: NDamian Nowak <spam@nowaker.net>
      URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181Signed-off-by: NNeilBrown <neilb@suse.de>
      b50c259e
    • N
      md/raid5: Fix possible confusion when multiple write errors occur. · 1cc03eb9
      NeilBrown 提交于
      commit 5d8c71f9
          md: raid5 crash during degradation
      
      Fixed a crash in an overly simplistic way which could leave
      R5_WriteError or R5_MadeGood set in the stripe cache for devices
      for which it is no longer relevant.
      When those devices are removed and spares added the flags are still
      set and can cause incorrect behaviour.
      
      commit 14a75d3e
          md/raid5: preferentially read from replacement device if possible.
      
      Fixed the same bug if a more effective way, so we can now revert
      the original commit.
      Reported-and-tested-by: NAlexander Lyakas <alex.bolshoy@gmail.com>
      Cc: stable@vger.kernel.org (3.2+ - 3.2 will need a different fix though)
      Fixes: 5d8c71f9Signed-off-by: NNeilBrown <neilb@suse.de>
      1cc03eb9
    • D
      Revert "drm: copy mode type in drm_mode_connector_list_update()" · abce1ec9
      Dave Airlie 提交于
      This reverts commit 3fbd6439.
      
      This caused some strange booting lockup issues on an Intel G33
      belonging to Daniel Vetter, very unusual, I was hoping Daniel
      would track this down, but it looks like instead I'll have to hack
      a different fix for -next.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      abce1ec9