1. 07 5月, 2010 2 次提交
  2. 23 4月, 2010 1 次提交
  3. 20 4月, 2010 1 次提交
  4. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  5. 16 3月, 2010 1 次提交
    • N
      md: deal with merge_bvec_fn in component devices better. · 627a2d3c
      NeilBrown 提交于
      If a component device has a merge_bvec_fn then as we never call it
      we must ensure we never need to.  Currently this is done by setting
      max_sector to 1 PAGE, however this does not stop a bio being created
      with several sub-page iovecs that would violate the merge_bvec_fn.
      
      So instead set max_segments to 1 and set the segment boundary to the
      same as a page boundary to ensure there is only ever one single-page
      segment of IO requested at a time.
      
      This can particularly be an issue when 'xen' is used as it is
      known to submit multiple small buffers in a single bio.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Cc: stable@kernel.org
      627a2d3c
  6. 08 3月, 2010 1 次提交
  7. 06 3月, 2010 14 次提交
  8. 26 2月, 2010 2 次提交
  9. 17 2月, 2010 8 次提交
    • T
      percpu: add __percpu sparse annotations to what's left · a29d8b8e
      Tejun Heo 提交于
      Add __percpu sparse annotations to places which didn't make it in one
      of the previous patches.  All converions are trivial.
      
      These annotations are to make sparse consider percpu variables to be
      in a different address space and warn if accessed without going
      through percpu accessors.  This patch doesn't affect normal builds.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Neil Brown <neilb@suse.de>
      a29d8b8e
    • A
      dm: sysfs revert add empty release function to avoid debug warning · 9307f6b1
      Alasdair G Kergon 提交于
      Revert commit d2bb7df8 at Greg's request.
      
          Author: Milan Broz <mbroz@redhat.com>
          Date:   Thu Dec 10 23:51:53 2009 +0000
      
          dm: sysfs add empty release function to avoid debug warning
      
          This patch just removes an unnecessary warning:
           kobject: 'dm': does not have a release() function,
           it is broken and must be fixed.
      
          The kobject is embedded in mapped device struct, so
          code does not need to release memory explicitly here.
      
      Cc: Greg KH <gregkh@suse.de>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      9307f6b1
    • K
      dm mpath: fix stall when requeueing io · 9eef87da
      Kiyoshi Ueda 提交于
      This patch fixes the problem that system may stall if target's ->map_rq
      returns DM_MAPIO_REQUEUE in map_request().
      E.g. stall happens on 1 CPU box when a dm-mpath device with queue_if_no_path
           bounces between all-paths-down and paths-up on I/O load.
      
      When target's ->map_rq returns DM_MAPIO_REQUEUE, map_request() requeues
      the request and returns to dm_request_fn().  Then, dm_request_fn()
      doesn't exit the I/O dispatching loop and continues processing
      the requeued request again.
      This map and requeue loop can be done with interrupt disabled,
      so 1 CPU system can be stalled if this situation happens.
      
      For example, commands below can stall my 1 CPU box within 1 minute or so:
        # dmsetup table mp
        mp: 0 2097152 multipath 1 queue_if_no_path 0 1 1 service-time 0 1 2 8:144 1 1
        # while true; do dd if=/dev/mapper/mp of=/dev/null bs=1M count=100; done &
        # while true; do \
        > dmsetup message mp 0 "fail_path 8:144" \
        > dmsetup suspend --noflush mp \
        > dmsetup resume mp \
        > dmsetup message mp 0 "reinstate_path 8:144" \
        > done
      
      To fix the problem above, this patch changes dm_request_fn() to exit
      the I/O dispatching loop once if a request is requeued in map_request().
      Signed-off-by: NKiyoshi Ueda <k-ueda@ct.jp.nec.com>
      Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      Cc: stable@kernel.org
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      9eef87da
    • T
      dm raid1: fix null pointer dereference in suspend · 558569aa
      Takahiro Yasui 提交于
      When suspending a failed mirror, bios are completed by mirror_end_io() and
      __rh_lookup() in dm_rh_dec() returns NULL where a non-NULL return value is
      required by design.  Fix this by not changing the state of the recovery failed
      region from DM_RH_RECOVERING to DM_RH_NOSYNC in dm_rh_recovery_end().
      
      Issue
      
      On 2.6.33-rc1 kernel, I hit the bug when I suspended the failed
      mirror by dmsetup command.
      
      BUG: unable to handle kernel NULL pointer dereference at 00000020
      IP: [<f94f38e2>] dm_rh_dec+0x35/0xa1 [dm_region_hash]
      ...
      EIP: 0060:[<f94f38e2>] EFLAGS: 00010046 CPU: 0
      EIP is at dm_rh_dec+0x35/0xa1 [dm_region_hash]
      EAX: 00000286 EBX: 00000000 ECX: 00000286 EDX: 00000000
      ESI: eff79eac EDI: eff79e80 EBP: f6915cd4 ESP: f6915cc4
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process dmsetup (pid: 2849, ti=f6914000 task=eff03e80 task.ti=f6914000)
       ...
      Call Trace:
       [<f9530af6>] ? mirror_end_io+0x53/0x1b1 [dm_mirror]
       [<f9413104>] ? clone_endio+0x4d/0xa2 [dm_mod]
       [<f9530aa3>] ? mirror_end_io+0x0/0x1b1 [dm_mirror]
       [<f94130b7>] ? clone_endio+0x0/0xa2 [dm_mod]
       [<c02d6bcb>] ? bio_endio+0x28/0x2b
       [<f952f303>] ? hold_bio+0x2d/0x62 [dm_mirror]
       [<f952f942>] ? mirror_presuspend+0xeb/0xf7 [dm_mirror]
       [<c02aa3e2>] ? vmap_page_range+0xb/0xd
       [<f9414c8d>] ? suspend_targets+0x2d/0x3b [dm_mod]
       [<f9414ca9>] ? dm_table_presuspend_targets+0xe/0x10 [dm_mod]
       [<f941456f>] ? dm_suspend+0x4d/0x150 [dm_mod]
       [<f941767d>] ? dev_suspend+0x55/0x18a [dm_mod]
       [<c0343762>] ? _copy_from_user+0x42/0x56
       [<f9417fb0>] ? dm_ctl_ioctl+0x22c/0x281 [dm_mod]
       [<f9417628>] ? dev_suspend+0x0/0x18a [dm_mod]
       [<f9417d84>] ? dm_ctl_ioctl+0x0/0x281 [dm_mod]
       [<c02c3c4b>] ? vfs_ioctl+0x22/0x85
       [<c02c422c>] ? do_vfs_ioctl+0x4cb/0x516
       [<c02c42b7>] ? sys_ioctl+0x40/0x5a
       [<c0202858>] ? sysenter_do_call+0x12/0x28
      
      Analysis
      
      When recovery process of a region failed, dm_rh_recovery_end() function
      changes the state of the region from RM_RH_RECOVERING to DM_RH_NOSYNC.
      When recovery_complete() is executed between dm_rh_update_states() and
      dm_writes() in do_mirror(), bios are processed with the region state,
      DM_RH_NOSYNC. However, the region data is freed without checking its
      pending count when dm_rh_update_states() is called next time.
      
      When bios are finished by mirror_end_io(), __rh_lookup() in dm_rh_dec()
      returns NULL even though a valid return value are expected.
      
      Solution
      
      Remove the state change of the recovery failed region from DM_RH_RECOVERING
      to DM_RH_NOSYNC in dm_rh_recovery_end(). We can remove the state change
      because:
      
        - If the region data has been released by dm_rh_update_states(),
          a new region data is created with the state of DM_RH_NOSYNC, and
          bios are processed according to the DM_RH_NOSYNC state.
      
        - If the region data has not been released by dm_rh_update_states(),
          a state of the region is DM_RH_RECOVERING and bios are put in the
          delayed_bio list.
      
      The flag change from DM_RH_RECOVERING to DM_RH_NOSYNC in dm_rh_recovery_end()
      was added in the following commit:
        dm raid1: handle resync failures
        author  Jonathan Brassow <jbrassow@redhat.com>
          Thu, 12 Jul 2007 16:29:04 +0000 (17:29 +0100)
        http://git.kernel.org/linus/f44db678edcc6f4c2779ac43f63f0b9dfa28b724Signed-off-by: NTakahiro Yasui <tyasui@redhat.com>
      Reviewed-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      558569aa
    • M
      dm raid1: fail writes if errors are not handled and log fails · 5528d17d
      Mikulas Patocka 提交于
      If the mirror log fails when the handle_errors option was not selected
      and there is no remaining valid mirror leg, writes return success even
      though they weren't actually written to any device.  This patch
      completes them with EIO instead.
      
      This code path is taken:
      do_writes:
      	bio_list_merge(&ms->failures, &sync);
      do_failures:
      	if (!get_valid_mirror(ms)) (false)
      	else if (errors_handled(ms)) (false)
      	else bio_endio(bio, 0);
      
      The logic in do_failures is based on presuming that the write was already
      tried: if it succeeded at least on one leg (without handle_errors) it
      is reported as success.
      
      Reference: https://bugzilla.redhat.com/show_bug.cgi?id=555197Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      5528d17d
    • J
      dm log: userspace fix overhead_size calcuations · ebfd32bb
      Jonathan Brassow 提交于
      This patch fixes two bugs that revolve around the miscalculation and
      misuse of the variable 'overhead_size'.  'overhead_size' is the size of
      the various header structures used during communication.
      
      The first bug is the use of 'sizeof' with the pointer of a structure
      instead of the structure itself - resulting in the wrong size being
      computed.  This is then used in a check to see if the payload
      (data_size) would be to large for the preallocated structure.  Since the
      bug produces a smaller value for the overhead, it was possible for the
      structure to be breached.  (Although the current users of the code do
      not currently send enough data to trigger this bug.)
      
      The second bug is that the 'overhead_size' value is used to compute how
      much of the preallocated space should be cleared before populating it
      with fresh data.  This should have simply been 'sizeof(struct cn_msg)'
      not overhead_size.  The fact that 'overhead_size' was computed
      incorrectly made this problem "less bad" - leaving only a pointer's
      worth of space at the end uncleared.  Thus, this bug was never producing
      a bad result, but still needs to be fixed - especially now that the
      value is computed correctly.
      
      Cc: stable@kernel.org
      Signed-off-by: Jonathan Brassow <jbrassow@redhat.com
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      ebfd32bb
    • M
      dm snapshot: persistent annotate work_queue as on stack · 55f67f2d
      Mike Snitzer 提交于
      chunk_io() declares its 'struct mdata_req' on the stack and then
      initializes its 'struct work_struct' member.  Annotate the
      initialization of this workqueue with INIT_WORK_ON_STACK to suppress a
      debugobjects warning seen when CONFIG_DEBUG_OBJECTS_WORK is enabled.
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      55f67f2d
    • N
      dm stripe: avoid divide by zero with invalid stripe count · 781248c1
      Nikanth Karthikesan 提交于
      If a table containing zero as stripe count is passed into stripe_ctr
      the code attempts to divide by zero.
      
      This patch changes DM_TABLE_LOAD to return -EINVAL if the stripe count
      is zero.
      
      We now get the following error messages:
        device-mapper: table: 253:0: striped: Invalid stripe count
        device-mapper: ioctl: error adding target to table
      Signed-off-by: NNikanth Karthikesan <knikanth@suse.de>
      Cc: stable@kernel.org
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      781248c1
  10. 10 2月, 2010 1 次提交
    • N
      md: fix some lockdep issues between md and sysfs. · ef286f6f
      NeilBrown 提交于
      ======
      This fix is related to
          http://bugzilla.kernel.org/show_bug.cgi?id=15142
      but does not address that exact issue.
      ======
      
      sysfs does like attributes being removed while they are being accessed
      (i.e. read or written) and waits for the access to complete.
      
      As accessing some md attributes takes the same lock that is held while
      removing those attributes a deadlock can occur.
      
      This patch addresses 3 issues in md that could lead to this deadlock.
      
      Two relate to calling flush_scheduled_work while the lock is held.
      This is probably a bad idea in general and as we use schedule_work to
      delete various sysfs objects it is particularly bad.
      
      In one case flush_scheduled_work is called from md_alloc (called by
      md_probe) called from do_md_run which holds the lock.  This call is
      only present to ensure that ->gendisk is set.  However we can be sure
      that gendisk is always set (though possibly we couldn't when that code
      was originally written.  This is because do_md_run is called in three
      different contexts:
        1/ from md_ioctl.  This requires that md_open has succeeded, and it
           fails if ->gendisk is not set.
        2/ from writing a sysfs attribute.  This can only happen if the
           mddev has been registered in sysfs which happens in md_alloc
           after ->gendisk has been set.
        3/ from autorun_array which is only called by autorun_devices, which
           checks for ->gendisk to be set before calling autorun_array.
      So the call to md_probe in do_md_run can be removed, and the check on
      ->gendisk can also go.
      
      
      In the other case flush_scheduled_work is being called in do_md_stop,
      purportedly to wait for all md_delayed_delete calls (which delete the
      component rdevs) to complete.  However there really isn't any need to
      wait for them - they have already been disconnected in all important
      ways.
      
      The third issue is that raid5->stop() removes some attribute names
      while the lock is held.  There is already some infrastructure in place
      to delay attribute removal until after the lock is released (using
      schedule_work).  So extend that infrastructure to remove the
      raid5_attrs_group.
      
      This does not address all lockdep issues related to the sysfs
      "s_active" lock.  The rest can be address by splitting that lockdep
      context between symlinks and non-symlinks which hopefully will happen.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      ef286f6f
  11. 09 2月, 2010 1 次提交
    • N
      md: fix 'degraded' calculation when starting a reshape. · 9eb07c25
      NeilBrown 提交于
      This code was written long ago when it was not possible to
      reshape a degraded array.  Now it is so the current level of
      degraded-ness needs to be taken in to account.  Also newly addded
      devices should only reduce degradedness if they are deemed to be
      in-sync.
      
      In particular, if you convert a RAID5 to a RAID6, and increase the
      number of devices at the same time, then the 5->6 conversion will
      make the array degraded so the current code will produce a wrong
      value for 'degraded' - "-1" to be precise.
      
      If the reshape runs to completion end_reshape will calculate a correct
      new value for 'degraded', but if a device fails during the reshape an
      incorrect decision might be made based on the incorrect value of
      "degraded".
      
      This patch is suitable for 2.6.32-stable and if they are still open,
      2.6.31-stable and 2.6.30-stable as well.
      
      Cc: stable@kernel.org
      Reported-by: NMichael Evans <mjevans1983@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      9eb07c25
  12. 11 1月, 2010 1 次提交
  13. 30 12月, 2009 5 次提交
    • N
      md: allow a resync that is waiting for other resync to complete, to be aborted. · 404e4b43
      NeilBrown 提交于
      If two arrays share a device, then they will not both resync at the
      same time.  One will wait for the other to complete.
      While waiting, the MD_RECOVERY_INTR flag is not checked so a device
      failure, which would make the resync pointless, does not cause the
      resync to abort, so the failed device cannot be removed (as it cannot
      be remove while a resync is happening).
      
      So add a test for MD_RECOVERY_INTR.
      Reported-by: NBrett Russ <bruss@netezza.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      404e4b43
    • N
      md: remove unnecessary code from do_md_run · 7fb9dadc
      NeilBrown 提交于
      Since commit dfc70645,
      ->hot_remove_disks has not removed non-failed devices from
      an array until recovery is no longer possible.
      So the code in do_md_run to get around the fact that
      md_check_recovery (which calls ->hot_remove_disks) would
      remove partially-in-sync devices is no longer needed.
      
      So remove it.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      7fb9dadc
    • D
      md: make recovery started by do_md_run() visible via sync_action · a2d79c32
      Dan Williams 提交于
      By default md_do_sync() will perform recovery if no other actions are
      specified.  However, action_show() relies on MD_RECOVERY_RECOVER to be
      set otherwise it returns 'idle'.  So, add a missing set
      MD_RECOVERY_RECOVER when starting recovery.
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      a2d79c32
    • N
      md: fix small irregularity with start_ro module parameter · 0f9552b5
      NeilBrown 提交于
      The start_ro modules parameter can be used to force arrays to be
      started in 'auto-readonly' in which they are read-only until the first
      write.  This ensures that no resync/recovery happens until something
      else writes to the device.  This is important for resume-from-disk
      off an md array.
      
      However if an array is started 'readonly' (by writing 'readonly' to
      the 'array_state' sysfs attribute) we want it to be really 'readonly',
      not 'auto-readonly'.
      
      So strengthen the condition to only set auto-readonly if the
      array is not already read-only.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      0f9552b5
    • N
      md: Fix unfortunate interaction with evms · cbd19983
      NeilBrown 提交于
      evms configures md arrays by:
        open device
        send ioctl
        close device
      
      for each different ioctl needed.
      Since 2.6.29, the device can disappear after the 'close'
      unless a significant configuration has happened to the device.
      The change made by "SET_ARRAY_INFO" can too minor to stop the device
      from disappearing, but important enough that losing the change is bad.
      
      So: make sure SET_ARRAY_INFO sets mddev->ctime, and keep the device
      active as long as ctime is non-zero (it gets zeroed with lots of other
      things when the array is stopped).
      
      This is suitable for -stable kernels since 2.6.29.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Cc: stable@kernel.org
      cbd19983
  14. 16 12月, 2009 1 次提交