1. 04 Aug, 2009 2 commits
    • Linus Torvalds's avatar
      tty-ldisc: turn ldisc user count into a proper refcount · 65b77046
      Linus Torvalds authored
      By using the user count for the actual lifetime rules, we can get rid of
      the silly "wait_for_idle" logic, because any busy ldisc will
      automatically stay around until the last user releases it.  This avoids
      a host of odd issues, and simplifies the code.
      
      So now, when the last ldisc reference is dropped, we just release the
      ldisc operations struct reference, and free the ldisc.
      
      It looks obvious enough, and it does work for me, but the counting
      _could_ be off. It probably isn't (bad counting in the new version would
      generally imply that the old code did something really bad, like free an
      ldisc with a non-zero count), but it does need some testing, and
      preferably somebody looking at it.
      
      With this change, both 'tty_ldisc_put()' and 'tty_ldisc_deref()' are
      just aliases for the new ref-counting 'put_ldisc()'. Both of them
      decrement the ldisc user count and free it if it goes down to zero.
      They're identical functions, in other words.
      
      But the reason they still exist as sepate functions is that one of them
      was exported (tty_ldisc_deref) and had a stupid name (so I don't want to
      use it as the main name), and the other one was used in multiple places
      (and I didn't want to make the patch larger just to rename the users).
      
      In addition to the refcounting, I did do some minimal cleanup. For
      example, now "tty_ldisc_try()" actually returns the ldisc it got under
      the lock, rather than returning true/false and then the caller would
      look up the ldisc again (now without the protection of the lock).
      
      That said, there's tons of dubious use of 'tty->ldisc' without obviously
      proper locking or refcounting left. I expressly did _not_ want to try to
      fix it all, keeping the patch minimal. There may or may not be bugs in
      that kind of code, but they wouldn't be _new_ bugs.
      
      That said, even if the bugs aren't new, the timing and lifetime will
      change. For example, some silly code may depend on the 'tty->ldisc'
      pointer not changing because they hold a refcount on the 'ldisc'. And
      that's no longer true - if you hold a ref on the ldisc, the 'ldisc'
      itself is safe, but tty->ldisc may change.
      
      So the proper locking (remains) to hold tty->ldisc_mutex if you expect
      tty->ldisc to be stable. That's not really a _new_ rule, but it's an
      example of something that the old code might have unintentionally
      depended on and hidden bugs.
      
      Whatever. The patch _looks_ sensible to me. The only users of
      ldisc->users are:
       - get_ldisc() - atomically increment the count
      
       - put_ldisc() - atomically decrements the count and releases if zero
      
       - tty_ldisc_try_get() - creates the ldisc, and sets the count to 1.
         The ldisc should then either be released, or be attached to a tty.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Tested-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Tested-by: default avatarSergey Senozhatsky <sergey.senozhatsky@mail.by>
      Acked-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      65b77046
    • Linus Torvalds's avatar
      tty-ldisc: make refcount be atomic_t 'users' count · 18eac1cc
      Linus Torvalds authored
      This is pure preparation of changing the ldisc reference counting to be
      a true refcount that defines the lifetime of the ldisc.  But this is a
      purely syntactic change for now to make the next steps easier.
      
      This patch should make no semantic changes at all. But I wanted to make
      the ldisc refcount be an atomic (I will be touching it without locks
      soon enough), and I wanted to rename it so that there isn't quite as
      much confusion between 'ldo->refcount' (ldisk operations refcount) and
      'ld->refcount' (ldisc refcount itself) in the same file.
      
      So it's now an atomic 'ld->users' count. It still starts at zero,
      despite having a reference from 'tty->ldisc', but that will change once
      we turn it into a _real_ refcount.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Tested-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Tested-by: default avatarSergey Senozhatsky <sergey.senozhatsky@mail.by>
      Acked-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      18eac1cc
  2. 03 Aug, 2009 8 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://neil.brown.name/md · a33a052f
      Linus Torvalds authored
      * 'for-linus' of git://neil.brown.name/md:
        md: Use revalidate_disk to effect changes in size of device.
        md: allow raid5_quiesce to work properly when reshape is happening.
        md/raid5: set reshape_position correctly when reshape starts.
        md: Handle growth of v1.x metadata correctly.
        md: avoid array overflow with bad v1.x metadata
        md: when a level change reduces the number of devices, remove the excess.
        md: Push down data integrity code to personalities.
        md/raid6: release spare page at ->stop()
      a33a052f
    • NeilBrown's avatar
      md: Use revalidate_disk to effect changes in size of device. · 449aad3e
      NeilBrown authored
      As revalidate_disk calls check_disk_size_change, it will cause
      any capacity change of a gendisk to be propagated to the blockdev
      inode.  So use that instead of mucking about with locks and
      i_size_write.
      
      Also add a call to revalidate_disk in do_md_run and a few other places
      where the gendisk capacity is changed.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      449aad3e
    • NeilBrown's avatar
      md: allow raid5_quiesce to work properly when reshape is happening. · 64bd660b
      NeilBrown authored
      The ->quiesce method is not supposed to stop resync/recovery/reshape,
      just normal IO.
      But in raid5 we don't have a way to know which stripes are being
      used for normal IO and which for resync etc, so we need to wait for
      all stripes to be idle to be sure that all writes have completed.
      
      However reshape keeps at least some stripe busy for an extended period
      of time, so a call to raid5_quiesce can block for several seconds
      needlessly.
      So arrange for reshape etc to pause briefly while raid5_quiesce is
      trying to quiesce the array so that the active_stripes count can
      drop to zero.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      64bd660b
    • NeilBrown's avatar
      md/raid5: set reshape_position correctly when reshape starts. · e516402c
      NeilBrown authored
      As the internal reshape_progress counter is the main driver
      for reshape, the fact that reshape_position sometimes starts with the
      wrong value has minimal effect.  It is visible in sysfs and that
      is all.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      e516402c
    • NeilBrown's avatar
      md: Handle growth of v1.x metadata correctly. · 70471daf
      NeilBrown authored
      The v1.x metadata does not have a fixed size and can grow
      when devices are added.
      If it grows enough to require an extra sector of storage,
      we need to update the 'sb_size' to match.
      
      Without this, md can write out an incomplete superblock with a
      bad checksum, which will be rejected when trying to re-assemble
      the array.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      70471daf
    • NeilBrown's avatar
      md: avoid array overflow with bad v1.x metadata · 3673f305
      NeilBrown authored
      We trust the 'desc_nr' field in v1.x metadata enough to use it
      as an index in an array.  This isn't really safe.
      So range-check the value first.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      3673f305
    • NeilBrown's avatar
      md: when a level change reduces the number of devices, remove the excess. · 3a981b03
      NeilBrown authored
      When an array is changed from RAID6 to RAID5, fewer drives are
      needed.  So any device that is made superfluous by the level
      conversion must be marked as not-active.
      For the RAID6->RAID5 conversion, this will be a drive which only
      has 'Q' blocks on it.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      3a981b03
    • Andre Noll's avatar
      md: Push down data integrity code to personalities. · ac5e7113
      Andre Noll authored
      This patch replaces md_integrity_check() by two new public functions:
      md_integrity_register() and md_integrity_add_rdev() which are both
      personality-independent.
      
      md_integrity_register() is called from the ->run and ->hot_remove
      methods of all personalities that support data integrity.  The
      function iterates over the component devices of the array and
      determines if all active devices are integrity capable and if their
      profiles match. If this is the case, the common profile is registered
      for the mddev via blk_integrity_register().
      
      The second new function, md_integrity_add_rdev() is called from the
      ->hot_add_disk methods, i.e. whenever a new device is being added
      to a raid array. If the new device does not support data integrity,
      or has a profile different from the one already registered, data
      integrity for the mddev is disabled.
      
      For raid0 and linear, only the call to md_integrity_register() from
      the ->run method is necessary.
      Signed-off-by: default avatarAndre Noll <maan@systemlinux.org>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      ac5e7113
  3. 02 Aug, 2009 21 commits
  4. 01 Aug, 2009 3 commits
  5. 31 Jul, 2009 6 commits