1. 13 11月, 2013 3 次提交
  2. 17 7月, 2013 1 次提交
    • D
      linked-list: Remove __list_for_each · c0d15cc7
      Dave Jones 提交于
      __list_for_each used to be the non prefetch() aware list walking
      primitive.  When we removed the prefetch macros from the list routines,
      it became redundant.  Given it does exactly the same thing as
      list_for_each now, we might as well remove it and call list_for_each
      directly.
      
      All users of __list_for_each have been converted to list_for_each calls
      in the current merge window.
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c0d15cc7
  3. 01 6月, 2013 1 次提交
  4. 15 3月, 2013 1 次提交
    • P
      list: Fix double fetch of pointer in hlist_entry_safe() · f65846a1
      Paul E. McKenney 提交于
      The current version of hlist_entry_safe() fetches the pointer twice,
      once to test for NULL and the other to compute the offset back to the
      enclosing structure.  This is OK for normal lock-based use because in
      that case, the pointer cannot change.  However, when the pointer is
      protected by RCU (as in "rcu_dereference(p)"), then the pointer can
      change at any time.  This use case can result in the following sequence
      of events:
      
      1.	CPU 0 invokes hlist_entry_safe(), fetches the RCU-protected
      	pointer as sees that it is non-NULL.
      
      2.	CPU 1 invokes hlist_del_rcu(), deleting the entry that CPU 0
      	just fetched a pointer to.  Because this is the last entry
      	in the list, the pointer fetched by CPU 0 is now NULL.
      
      3.	CPU 0 refetches the pointer, obtains NULL, and then gets a
      	NULL-pointer crash.
      
      This commit therefore applies gcc's "({ })" statement expression to
      create a temporary variable so that the specified pointer is fetched
      only once, avoiding the above sequence of events.  Please note that
      it is the caller's responsibility to use rcu_dereference() as needed.
      This allows RCU-protected uses to work correctly without imposing
      any additional overhead on the non-RCU case.
      
      Many thanks to Eric Dumazet for spotting root cause!
      Reported-by: NCAI Qian <caiqian@redhat.com>
      Reported-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Tested-by: NLi Zefan <lizefan@huawei.com>
      f65846a1
  5. 28 2月, 2013 1 次提交
    • S
      hlist: drop the node parameter from iterators · b67bfe0d
      Sasha Levin 提交于
      I'm not sure why, but the hlist for each entry iterators were conceived
      
              list_for_each_entry(pos, head, member)
      
      The hlist ones were greedy and wanted an extra parameter:
      
              hlist_for_each_entry(tpos, pos, head, member)
      
      Why did they need an extra pos parameter? I'm not quite sure. Not only
      they don't really need it, it also prevents the iterator from looking
      exactly like the list iterator, which is unfortunate.
      
      Besides the semantic patch, there was some manual work required:
      
       - Fix up the actual hlist iterators in linux/list.h
       - Fix up the declaration of other iterators based on the hlist ones.
       - A very small amount of places were using the 'node' parameter, this
       was modified to use 'obj->member' instead.
       - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
       properly, so those had to be fixed up manually.
      
      The semantic patch which is mostly the work of Peter Senna Tschudin is here:
      
      @@
      iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
      
      type T;
      expression a,c,d,e;
      identifier b;
      statement S;
      @@
      
      -T b;
          <+... when != b
      (
      hlist_for_each_entry(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue(a,
      - b,
      c) S
      |
      hlist_for_each_entry_from(a,
      - b,
      c) S
      |
      hlist_for_each_entry_rcu(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_rcu_bh(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue_rcu_bh(a,
      - b,
      c) S
      |
      for_each_busy_worker(a, c,
      - b,
      d) S
      |
      ax25_uid_for_each(a,
      - b,
      c) S
      |
      ax25_for_each(a,
      - b,
      c) S
      |
      inet_bind_bucket_for_each(a,
      - b,
      c) S
      |
      sctp_for_each_hentry(a,
      - b,
      c) S
      |
      sk_for_each(a,
      - b,
      c) S
      |
      sk_for_each_rcu(a,
      - b,
      c) S
      |
      sk_for_each_from
      -(a, b)
      +(a)
      S
      + sk_for_each_from(a) S
      |
      sk_for_each_safe(a,
      - b,
      c, d) S
      |
      sk_for_each_bound(a,
      - b,
      c) S
      |
      hlist_for_each_entry_safe(a,
      - b,
      c, d, e) S
      |
      hlist_for_each_entry_continue_rcu(a,
      - b,
      c) S
      |
      nr_neigh_for_each(a,
      - b,
      c) S
      |
      nr_neigh_for_each_safe(a,
      - b,
      c, d) S
      |
      nr_node_for_each(a,
      - b,
      c) S
      |
      nr_node_for_each_safe(a,
      - b,
      c, d) S
      |
      - for_each_gfn_sp(a, c, d, b) S
      + for_each_gfn_sp(a, c, d) S
      |
      - for_each_gfn_indirect_valid_sp(a, c, d, b) S
      + for_each_gfn_indirect_valid_sp(a, c, d) S
      |
      for_each_host(a,
      - b,
      c) S
      |
      for_each_host_safe(a,
      - b,
      c, d) S
      |
      for_each_mesh_entry(a,
      - b,
      c, d) S
      )
          ...+>
      
      [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
      [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
      [akpm@linux-foundation.org: checkpatch fixes]
      [akpm@linux-foundation.org: fix warnings]
      [akpm@linux-foudnation.org: redo intrusive kvm changes]
      Tested-by: NPeter Senna Tschudin <peter.senna@gmail.com>
      Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b67bfe0d
  6. 20 5月, 2011 2 次提交
    • L
      list: remove prefetching from regular list iterators · e66eed65
      Linus Torvalds 提交于
      This is removes the use of software prefetching from the regular list
      iterators.  We don't want it.  If you do want to prefetch in some
      iterator of yours, go right ahead.  Just don't expect the iterator to do
      it, since normally the downsides are bigger than the upsides.
      
      It also replaces <linux/prefetch.h> with <linux/const.h>, because the
      use of LIST_POISON ends up needing it.  <linux/poison.h> is sadly not
      self-contained, and including prefetch.h just happened to hide that.
      
      Suggested by David Miller (networking has a lot of regular lists that
      are often empty or a single entry, and prefetching is not going to do
      anything but add useless instructions).
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Cc: linux-arch@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e66eed65
    • L
      hlist: remove software prefetching in hlist iterators · 75d65a42
      Linus Torvalds 提交于
      They not only increase the code footprint, they actually make things
      slower rather than faster.  On internationally acclaimed benchmarks
      ("make -j16" on an already fully built kernel source tree) the hlist
      prefetching slows down the build by up to 1%.
      
      (Almost all of it comes from hlist_for_each_entry_rcu() as used by
      avc_has_perm_noaudit(), which is very hot due to all the pathname
      lookups to see if there is anything to do).
      
      The cause seems to be two-fold:
      
       - on at least some Intel cores, prefetch(NULL) ends up with some
         microarchitectural stall due to the TLB miss that it incurs.  The
         hlist case triggers this very commonly, since the NULL pointer is the
         last entry in the list.
      
       - the prefetch appears to cause more D$ activity, probably because it
         prefetches hash list entries that are never actually used (because we
         ended the search early due to a hit).
      
      Regardless, the numbers clearly say that the implicit prefetching is
      simply a bad idea.  If some _particular_ user of the hlist iterators
      wants to prefetch the next list entry, they can do so themselves
      explicitly, rather than depend on all list iterators doing so
      implicitly.
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Cc: linux-arch@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      75d65a42
  7. 19 2月, 2011 1 次提交
    • L
      Expand CONFIG_DEBUG_LIST to several other list operations · 3c18d4de
      Linus Torvalds 提交于
      When list debugging is enabled, we aim to readably show list corruption
      errors, and the basic list_add/list_del operations end up having extra
      debugging code in them to do some basic validation of the list entries.
      
      However, "list_del_init()" and "list_move[_tail]()" ended up avoiding
      the debug code due to how they were written. This fixes that.
      
      So the _next_ time we have list_move() problems with stale list entries,
      we'll hopefully have an easier time finding them..
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3c18d4de
  8. 26 10月, 2010 1 次提交
  9. 07 10月, 2010 1 次提交
  10. 07 7月, 2010 1 次提交
    • C
      Move list types from <linux/list.h> to <linux/types.h>. · de5d9bf6
      Chris Metcalf 提交于
      This allows a list_head (or hlist_head, etc.) to be used from places
      that used to be impractical, in particular <asm/processor.h>, which
      used to cause include file recursion: <linux/list.h> includes
      <linux/prefetch.h>, which always includes <asm/processor.h> for the
      prefetch macros, as well as <asm/system.h>, which often includes
      <asm/processor.h> directly or indirectly.
      
      This avoids a lot of painful workaround hackery on the tile
      architecture, where we use a list_head in the thread_struct to chain
      together tasks that are activated on a particular hardwall.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      Reviewed-by: NMatthew Wilcox <willy@linux.intel.com>
      de5d9bf6
  11. 30 6月, 2010 1 次提交
    • N
      fs: fix superblock iteration race · 57439f87
      npiggin@suse.de 提交于
      list_for_each_entry_safe is not suitable to protect against concurrent
      modification of the list. 6754af64 introduced a race in sb walking.
      
      list_for_each_entry can use the trick of pinning the current entry in
      the list before we drop and retake the lock because it subsequently
      follows cur->next. However list_for_each_entry_safe saves n=cur->next
      for following before entering the loop body, so when the lock is
      dropped, n may be deleted.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: John Stultz <johnstul@us.ibm.com>
      Cc: Frank Mayhar <fmayhar@google.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      57439f87
  12. 07 3月, 2010 1 次提交
  13. 16 1月, 2010 1 次提交
  14. 01 9月, 2008 1 次提交
    • V
      debugobjects: fix lockdep warning · 673d62cc
      Vegard Nossum 提交于
      Daniel J. Blueman reported:
      > =======================================================
      > [ INFO: possible circular locking dependency detected ]
      > 2.6.27-rc4-224c #1
      > -------------------------------------------------------
      > hald/4680 is trying to acquire lock:
      >  (&n->list_lock){++..}, at: [<ffffffff802bfa26>] add_partial+0x26/0x80
      >
      > but task is already holding lock:
      >  (&obj_hash[i].lock){++..}, at: [<ffffffff8041cfdc>]
      > debug_object_free+0x5c/0x120
      
      We fix it by moving the actual freeing to outside the lock (the lock
      now only protects the list).
      
      The pool lock is also promoted to irq-safe (suggested by Dan). It's
      necessary because free_pool is now called outside the irq disabled
      region. So we need to protect against an interrupt handler which calls
      debug_object_init().
      
      [tglx@linutronix.de: added hlist_move_list helper to avoid looping
      		     through the list twice]
      Reported-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      673d62cc
  15. 09 8月, 2008 1 次提交
  16. 07 8月, 2008 2 次提交
  17. 26 7月, 2008 1 次提交
  18. 19 5月, 2008 1 次提交
  19. 30 4月, 2008 1 次提交
  20. 29 4月, 2008 1 次提交
  21. 28 4月, 2008 1 次提交
  22. 21 4月, 2008 1 次提交
  23. 20 10月, 2007 1 次提交
    • R
      kernel-api docbook: fix content problems · 8f731f7d
      Randy Dunlap 提交于
      Fix kernel-api docbook contents problems.
      
      docproc: linux-2.6.23-git13/include/asm-x86/unaligned_32.h: No such file or directory
      Warning(linux-2.6.23-git13//include/linux/list.h:482): bad line: 			of list entry
      Warning(linux-2.6.23-git13//mm/filemap.c:864): No description found for parameter 'ra'
      Warning(linux-2.6.23-git13//block/ll_rw_blk.c:3760): No description found for parameter 'req'
      Warning(linux-2.6.23-git13//include/linux/input.h:1077): No description found for parameter 'private'
      Warning(linux-2.6.23-git13//include/linux/input.h:1077): No description found for parameter 'cdev'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: WU Fengguang <wfg@mail.ustc.edu.cn>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f731f7d
  24. 17 10月, 2007 1 次提交
    • D
      shrink_dcache_sb speedup · 37c42524
      Denis V. Lunev 提交于
      This patch makes shrink_dcache_sb consistent with dentry pruning policy.
      
      On the first pass we iterate over dentry unused list and prepare some
      dentries for removal.
      
      However, since the existing code moves evicted dentries to the beginning of
      the LRU it can happen that fresh dentries from other superblocks will be
      inserted *before* our dentries.
      
      This can result in significant slowdown of shrink_dcache_sb().  Moreover,
      for virtual filesystems like unionfs which can call dput() during dentries
      kill existing code results in O(n^2) complexity.
      
      We observed 2 minutes shrink_dcache_sb() with only 35000 dentries.
      
      To avoid this effects we propose to isolate sb dentries at the end
      of LRU list.
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Signed-off-by: NKirill Korotaev <dev@openvz.org>
      Signed-off-by: NAndrey Mirkin <amirkin@openvz.org>
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      37c42524
  25. 11 10月, 2007 1 次提交
  26. 13 5月, 2007 1 次提交
  27. 09 5月, 2007 1 次提交
    • P
      Introduce a handy list_first_entry macro · b5e61818
      Pavel Emelianov 提交于
      There are many places in the kernel where the construction like
      
         foo = list_entry(head->next, struct foo_struct, list);
      
      are used.
      The code might look more descriptive and neat if using the macro
      
         list_first_entry(head, type, member) \
                   list_entry((head)->next, type, member)
      
      Here is the macro itself and the examples of its usage in the generic code.
       If it will turn out to be useful, I can prepare the set of patches to
      inject in into arch-specific code, drivers, networking, etc.
      Signed-off-by: NPavel Emelianov <xemul@openvz.org>
      Signed-off-by: NKirill Korotaev <dev@openvz.org>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Zach Brown <zach.brown@oracle.com>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: John McCutchan <ttb@tentacle.dhs.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b5e61818
  28. 12 2月, 2007 2 次提交
  29. 27 1月, 2007 1 次提交
  30. 30 9月, 2006 1 次提交
  31. 15 7月, 2006 1 次提交
  32. 28 6月, 2006 1 次提交
  33. 26 6月, 2006 2 次提交
  34. 23 6月, 2006 1 次提交