user/sven/linux.git/include/linux/list.h, branch v4.4.159

rculist: Use WRITE_ONCE() when deleting from reader-visible list

2015-10-06T18:16:42Z

The various RCU list-deletion macros (list_del_rcu(), hlist_del_init_rcu(), hlist_del_rcu(), hlist_bl_del_init_rcu(), hlist_bl_del_rcu(), hlist_nulls_del_init_rcu(), and hlist_nulls_del_rcu()) do plain stores into the ->next pointer of the preceding list elemment. Unfortunately, the compiler is within its rights to (for example) use byte-at-a-time writes to update the pointer, which would fatally confuse concurrent readers. This patch therefore adds the needed WRITE_ONCE() macros. KernelThreadSanitizer (KTSAN) reported the __hlist_del() issue, which is a problem when __hlist_del() is invoked by hlist_del_rcu(). Reported-by: Dmitry Vyukov Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett

inode: add hlist_fake to avoid the inode hash lock in evict

2015-08-17T22:39:45Z

Some filesystems don't use the VFS inode hash and fake the fact they are hashed so that all the writeback code works correctly. However, this means the evict() path still tries to remove the inode from the hash, meaning that the inode_hash_lock() needs to be taken unnecessarily. Hence under certain workloads the inode_hash_lock can be contended even if the inode is never actually hashed. To avoid this add hlist_fake to test if the inode isn't actually hashed to avoid taking the hash lock on inodes that have never been hashed. Based on Dave Chinner's inode: add IOP_NOTHASHED to avoid inode hash lock in evict basd on Al's suggestions. Thanks, Signed-off-by: Josef Bacik Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig Tested-by: Dave Chinner

Replace mentions of "list_struct" to "list_head"

2014-11-20T13:45:15Z

There's no such thing as "list_struct". Signed-off-by: Andrey Utkin Acked-by: Steven Rostedt Acked-by: Mauro Carvalho Chehab Acked-by: Paul E. McKenney Acked-by: Alex Deucher Signed-off-by: Jiri Kosina

list: include linux/kernel.h

2014-10-14T00:18:13Z

linux/list.h uses container_of, therefore it depends on linux/kernel.h. Signed-off-by: Masahiro Yamada Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

list: fix order of arguments for hlist_add_after(_rcu)

2014-08-07T01:01:24Z

All other add functions for lists have the new item as first argument and the position where it is added as second argument. This was changed for no good reason in this function and makes using it unnecessary confusing. The name was changed to hlist_add_behind() to cause unconverted code to generate a compile error instead of using the wrong parameter order. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Ken Helias Cc: "Paul E. McKenney" Acked-by: Jeff Kirsher [intel driver bits] Cc: Hugh Dickins Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

list: make hlist_add_after() argument names match hlist_add_after_rcu()

2014-08-07T01:01:24Z

The argument names for hlist_add_after() are poorly chosen because they look the same as the ones for hlist_add_before() but have to be used differently. hlist_add_after_rcu() has made a better choice. Signed-off-by: Ken Helias Cc: "Paul E. McKenney" Cc: Christoph Hellwig Cc: Hugh Dickins Cc: Jeff Kirsher Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

list: introduce list_last_entry(), use list_{first,last}_entry()

2013-11-13T03:09:24Z

We already have list_first_entry(), it makes sense to also add list_last_entry() for consistency. And we use both helpers in list_for_each_*(). Signed-off-by: Oleg Nesterov Cc: Eilon Greenstein Cc: Greg Kroah-Hartman Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

list: change list_for_each_entry() to use list__entry()

2013-11-13T03:09:23Z

Now that we have list_{next,prev}_entry() we can change list_for_each_entry*() and list_safe_reset_next() to use the new helpers to improve the readability. Signed-off-by: Oleg Nesterov Cc: Eilon Greenstein Cc: Greg Kroah-Hartman Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

list: introduce list_next_entry() and list_prev_entry()

2013-11-13T03:09:23Z

Add two trivial helpers list_next_entry() and list_prev_entry(), they can have a lot of users including list.h itself. In fact the 1st one is already defined in events/core.c and bnx2x_sp.c, so the patch simply moves the definition to list.h. Signed-off-by: Oleg Nesterov Cc: Eilon Greenstein Cc: Greg Kroah-Hartman Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

linked-list: Remove __list_for_each

2013-07-17T05:00:14Z

__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: Dave Jones Signed-off-by: Linus Torvalds

user/sven/linux.git/include/linux/list.h, branch v4.4.159

rculist: Use WRITE_ONCE() when deleting from reader-visible list

inode: add hlist_fake to avoid the inode hash lock in evict

Replace mentions of "list_struct" to "list_head"

list: include linux/kernel.h

list: fix order of arguments for hlist_add_after(_rcu)

list: make hlist_add_after() argument names match hlist_add_after_rcu()

list: introduce list_last_entry(), use list_{first,last}_entry()

list: change list_for_each_entry*() to use list_*_entry()

list: introduce list_next_entry() and list_prev_entry()

linked-list: Remove __list_for_each

list: change list_for_each_entry() to use list__entry()