Files
kernel-eswin-eic7700/include/linux
Tejun Heo c34ac00cae rculist: list_first_or_null_rcu() should use list_entry_rcu()
list_first_or_null() should test whether the list is empty and return
pointer to the first entry if not in a RCU safe manner.  It's broken
in several ways.

* It compares __kernel @__ptr with __rcu @__next triggering the
  following sparse warning.

  net/core/dev.c:4331:17: error: incompatible types in comparison expression (different address spaces)

* It doesn't perform rcu_dereference*() and computes the entry address
  using container_of() directly from the __rcu pointer which is
  inconsitent with other rculist interface.  As a result, all three
  in-kernel users - net/core/dev.c, macvlan, cgroup - are buggy.  They
  dereference the pointer w/o going through read barrier.

* While ->next dereference passes through list_next_rcu(), the
  compiler is still free to fetch ->next more than once and thus
  nullify the "__ptr != __next" condition check.

Fix it by making list_first_or_null_rcu() dereference ->next directly
using ACCESS_ONCE() and then use list_entry_rcu() on it like other
rculist accessors.

v2: Paul pointed out that the compiler may fetch the pointer more than
    once nullifying the condition check.  ACCESS_ONCE() added on
    ->next dereference.

v3: Restored () around macro param which was accidentally removed.
    Spotted by Paul.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Dipankar Sarma <dipankar@in.ibm.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: stable@vger.kernel.org
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
2013-08-18 17:40:16 -07:00
..
2013-06-27 13:42:16 -04:00
2013-03-01 13:39:00 -08:00
2013-07-02 22:08:20 +01:00
2013-06-17 14:38:54 -04:00
2013-05-07 19:46:02 -07:00
2013-05-29 15:50:34 -04:00
2013-04-29 15:40:23 -04:00
2013-07-03 16:07:39 -07:00
2013-03-23 16:11:31 -07:00
2013-03-22 15:18:18 -07:00
2013-03-12 11:30:04 -07:00
2013-07-10 23:41:18 +01:00
2013-05-01 16:36:22 +05:30
2013-03-28 10:10:25 -06:00
2013-02-26 02:46:08 -05:00
2013-05-07 18:38:27 -07:00
2013-03-15 15:09:43 +10:30
2013-04-29 18:28:40 -07:00
2013-06-17 16:38:57 -07:00
2013-06-19 23:32:07 -04:00
2013-06-10 13:45:49 -07:00
2013-05-06 13:07:33 +02:00
2013-07-03 16:07:32 -07:00
2013-06-13 17:51:04 -07:00
2013-07-18 13:05:23 -07:00
2013-06-17 16:38:57 -07:00
2013-04-30 17:04:06 -07:00
2013-04-01 11:04:50 -07:00
2013-07-16 22:00:14 -07:00
2013-07-09 10:33:30 -07:00
2013-05-31 00:48:22 -07:00
2013-07-10 18:11:34 -07:00
2013-03-15 15:09:43 +10:30
2013-07-02 15:38:19 +09:30
2013-07-03 16:08:05 -07:00
2013-06-08 16:20:14 -04:00
2013-05-04 14:47:26 -04:00
2013-06-12 12:37:40 +01:00
2013-06-12 12:37:30 +01:00
2013-04-29 15:54:28 -07:00
2013-06-26 15:55:52 -06:00
2013-06-26 21:10:05 +02:00
2013-05-31 17:19:05 -07:00
2013-06-21 11:32:51 +02:00
2013-04-29 15:54:28 -07:00
2013-04-12 10:26:23 +02:00
2013-07-03 16:08:05 -07:00
2013-07-10 18:11:34 -07:00
2013-06-17 16:38:57 -07:00
2013-06-17 18:09:53 +09:00
2013-03-29 15:31:30 -04:00
2013-07-05 11:41:00 +05:30
2013-06-20 13:08:01 -07:00
2013-04-30 15:50:12 +05:30
2013-05-21 12:25:02 -05:00
2013-03-20 12:10:38 -04:00
2013-04-29 15:54:37 -07:00
2013-05-27 10:57:53 +09:00
2013-07-10 18:11:34 -07:00