1. 03 Jul, 2008 13 commits
  2. 02 Jul, 2008 7 commits
  3. 01 Jul, 2008 4 commits
  4. 30 Jun, 2008 6 commits
  5. 27 Jun, 2008 8 commits
    • Li Zefan's avatar
      CONNECTOR: add a proc entry to list connectors · a0a61a60
      Li Zefan authored
      
      
      I got a problem when I wanted to check if the kernel supports process
      event connector, and It seems there's no way to do this check.
      
      At best I can check if the kernel supports connector or not, by looking
      into /proc/net/netlink, or maybe checking the return value of bind() to
      see if it's ENOENT.
      
      So it would be useful to add /proc/net/connector to list all supported
      connectors:
       # cat /proc/net/connector
       Name            ID
       connector       4294967295:4294967295
       cn_proc         1:1
       w1              3:1
      
      Changelog:
      - fix memory leak: s/seq_release/single_release
      - use spin_lock_bh instead of spin_lock_irqsave
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: default avatarEvgeniy Polyakov <johnpol@2ka.mipt.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0a61a60
    • Andre Haupt's avatar
      hamradio: remove unused variable · 47979821
      Andre Haupt authored
      
      Signed-off-by: default avatarAndre Haupt <andre@bitwigglers.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47979821
    • Neil Brown's avatar
      Fix error paths if md_probe fails. · 9bbbca3a
      Neil Brown authored
      
      
      md_probe can fail (e.g. alloc_disk could fail) without
      returning an error (as it alway returns NULL).
      So when we call mddev_find immediately afterwards, we need
      to check that md_probe actually succeeded.  This means checking
      that mdev->gendisk is non-NULL.
      
      cc: <stable@kernel.org>
      Cc: Dave Jones <davej@redhat.com>
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      9bbbca3a
    • Neil Brown's avatar
      Don't acknowlege that stripe-expand is complete until it really is. · efe31143
      Neil Brown authored
      
      
      We shouldn't acknowledge that a stripe has been expanded (When
      reshaping a raid5 by adding a device) until the moved data has
      actually been written out.  However we are currently
      acknowledging (by calling md_done_sync) when the POST_XOR
      is complete and before the write.
      
      So track in s.locked whether there are pending writes, and don't
      call md_done_sync yet if there are.
      
      Note: we all set R5_LOCKED on devices which are are about to
      read from.  This probably isn't technically necessary, but is
      usually done when writing a block, and justifies the use of
      s.locked here.
      
      This bug can lead to a crash if an array is stopped while an reshape
      is in progress.
      
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      efe31143
    • Neil Brown's avatar
      Ensure interrupted recovery completed properly (v1 metadata plus bitmap) · 8c2e870a
      Neil Brown authored
      
      
      If, while assembling an array, we find a device which is not fully
      in-sync with the array, it is important to set the "fullsync" flags.
      This is an exact analog to the setting of this flag in hot_add_disk
      methods.
      
      Currently, only v1.x metadata supports having devices in an array
      which are not fully in-sync (it keep track of how in sync they are).
      The 'fullsync' flag only makes a difference when a write-intent bitmap
      is being used.  In this case it tells recovery to ignore the bitmap
      and recovery all blocks.
      
      This fix is already in place for raid1, but not raid5/6 or raid10.
      
      So without this fix, a raid1 ir raid4/5/6 array with version 1.x
      metadata and a write intent bitmaps, that is stopped in the middle
      of a recovery, will appear to complete the recovery instantly
      after it is reassembled, but the recovery will not be correct.
      
      If you might have an array like that, issueing
         echo repair > /sys/block/mdXX/md/sync_action
      
      will make sure recovery completes properly.
      
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      8c2e870a
    • Richard Sharpe's avatar
      firewire: fw-sbp2: fix parsing of logical unit directories · 0e3e2eab
      Richard Sharpe authored
      
      
      There is a small off-by-one bug in firewire-sbp2. This causes problems
      when a device exports multiple LUN Directories. I found it when trying
      to talk to a SONY DVD Jukebox.
      Signed-off-by: default avatarRichard Sharpe <realrichardsharpe@gmail.com>
      Acked-by: default avatarKristian Høgsberg <krh@redhat.com>
      Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (op. order, changelog)
      0e3e2eab
    • Harvey Harrison's avatar
      prism: islpci_eth.c endianness fix · 5f4a6fae
      Harvey Harrison authored
      
      
      clock is already cpu-endian (see le32_to_cpu slightly before), so
      le64_to_cpu doesn't make much sense.
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5f4a6fae
    • Ivo van Doorn's avatar
      rt2x00: Fix lock dependency errror · 980dfcb9
      Ivo van Doorn authored
      
      
      This fixes a circular locking dependency in the workqueue handling.
      The interface work task uses the mac80211 function
      ieee80211_iterate_active_interfaces() which grabs the RTNL lock.
      
      However when the interface is brough down, this happens under the RTNL
      lock as well, this causes problems because mac80211 will flush the workqueue
      during the ifdown event. This causes mac80211 to wait until the driver has
      completed all work which can't finish because it is waiting on the RTNL lock.
      
      This is fixed by moving rt2x00 workqueue tasks on a different workqueue,
      this workqueue can be flushed when the ieee80211_hw structure is removed
      by the driver (when the driver is unloaded) which does not happen under the
      RTNL lock.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      980dfcb9
  6. 26 Jun, 2008 2 commits