1. 12 7月, 2007 3 次提交
    • T
      ida: implement idr based id allocator · 72dba584
      Tejun Heo 提交于
      Implement idr based id allocator.  ida is used the same way idr is
      used but lacks id -> ptr translation and thus consumes much less
      memory.  struct ida_bitmap is attached as leaf nodes to idr tree which
      is managed by the idr code.  Each ida_bitmap is 128bytes long and
      contains slightly less than a thousand slots.
      
      ida is more aggressive with releasing extra resources acquired using
      ida_pre_get().  After every successful id allocation, ida frees one
      reserved idr_layer if possible.  Reserved ida_bitmap is not freed
      automatically but only one ida_bitmap is reserved and it's almost
      always used right away.  Under most circumstances, ida won't hold on
      to memory for too long which isn't actively used.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      72dba584
    • T
      idr: separate out idr_mark_full() · e33ac8bd
      Tejun Heo 提交于
      Separate out idr_mark_full() from sub_alloc() and make marking the
      allocated slot full the responsibility of idr_get_new_above_int().
      
      Allocation part of idr_get_new_above_int() is renamed to
      idr_get_empty_slot().  New idr_get_new_above_int() allocates a slot
      using the function, install the user pointer and marks it full using
      idr_mark_full().
      
      This change doesn't introduce any behavior change.  This will be
      used by ida.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e33ac8bd
    • T
      idr: fix obscure bug in allocation path · 7aae6dd8
      Tejun Heo 提交于
      In sub_alloc(), when bitmap search fails, it goes up one level to
      continue search.  This is done by updating the id cursor and searching
      the upper level again.  If the cursor was at the end of the upper
      level, we need to go further than that.
      
      This wasn't implemented and when that happens the part of the cursor
      which indexes into the upper level wraps and sub_alloc() ends up
      searching the wrong bitmap.  It allocates id which doesn't match the
      actual slot.
      
      This patch fixes this by restarting from the top if the search needs
      to go higher than one level.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      7aae6dd8
  2. 12 2月, 2007 1 次提交
  3. 08 12月, 2006 1 次提交
  4. 15 7月, 2006 1 次提交
    • R
      [PATCH] Convert idr's internal locking to _irqsave variant · c259cc28
      Roland Dreier 提交于
      Currently, the code in lib/idr.c uses a bare spin_lock(&idp->lock) to do
      internal locking.  This is a nasty trap for code that might call idr
      functions from different contexts; for example, it seems perfectly
      reasonable to call idr_get_new() from process context and idr_remove() from
      interrupt context -- but with the current locking this would lead to a
      potential deadlock.
      
      The simplest fix for this is to just convert the idr locking to use
      spin_lock_irqsave().
      
      In particular, this fixes a very complicated locking issue detected by
      lockdep, involving the ib_ipoib driver's priv->lock and dev->_xmit_lock,
      which get involved with the ib_sa module's query_idr.lock.
      
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Zach Brown <zach.brown@oracle.com>,
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c259cc28
  5. 27 6月, 2006 1 次提交
  6. 26 6月, 2006 1 次提交
    • S
      [PATCH] fix race in idr code · 1eec0056
      Sonny Rao 提交于
      I ran into a bug where the kernel died in the idr code:
      
      cpu 0x1d: Vector: 300 (Data Access) at [c000000b7096f710]
          pc: c0000000001f8984: .idr_get_new_above_int+0x140/0x330
          lr: c0000000001f89b4: .idr_get_new_above_int+0x170/0x330
          sp: c000000b7096f990
         msr: 800000000000b032
         dar: 0
       dsisr: 40010000
        current = 0xc000000b70d43830
        paca    = 0xc000000000556900
          pid   = 2022, comm = hwup
      1d:mon> t
      [c000000b7096f990] c0000000000d2ad8 .expand_files+0x2e8/0x364 (unreliable)
      [c000000b7096faa0] c0000000001f8bf8 .idr_get_new_above+0x18/0x68
      [c000000b7096fb20] c00000000002a054 .init_new_context+0x5c/0xf0
      [c000000b7096fbc0] c000000000049dc8 .copy_process+0x91c/0x1404
      [c000000b7096fcd0] c00000000004a988 .do_fork+0xd8/0x224
      [c000000b7096fdc0] c00000000000ebdc .sys_clone+0x5c/0x74
      [c000000b7096fe30] c000000000008950 .ppc_clone+0x8/0xc
      1eec0056
  7. 31 10月, 2005 1 次提交
  8. 28 10月, 2005 1 次提交
  9. 24 10月, 2005 1 次提交
    • A
      [PATCH] inotify/idr leak fix · 8d3b3591
      Andrew Morton 提交于
      Fix a bug which was reported and diagnosed by
      Stefan Jones <stefan.jones@churchillrandoms.co.uk>
      
      IDR trees include a cache of idr_layer objects.  There's no way to destroy
      this cache, so when we discard an overall idr tree we end up leaking some
      memory.
      
      Add and use idr_destroy() for this.  v9fs and infiniband also need to use
      idr_destroy() to avoid leaks.
      
      Or, we make the cache global, like radix_tree_preload().  Which is probably
      better.  Later.
      
      Cc: Eric Van Hensbergen <ericvh@ericvh.myip.org>
      Cc: Roland Dreier <rolandd@cisco.com>
      Cc: Robert Love <rml@novell.com>
      Cc: John McCutchan <ttb@tentacle.dhs.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8d3b3591
  10. 27 8月, 2005 1 次提交
  11. 22 6月, 2005 1 次提交
  12. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4