| Message ID | 20230615181004.86850-2-sj@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Docs/RCU/rculist_nulls: Minor fixup | expand |
> 2023年6月16日 02:10，SeongJae Park <sj@kernel.org> 写道： > > The type of 'obj' in example code of rculist_nulls.rst is implicit. > Provide the specific type of it before the example code. > > Suggested-by: aul E. McKenney <paulmck@kernel.org> Paul E. McKenney > Link: https://lore.kernel.org/rcu/43943609-f80c-4b6a-9844-994eef800757@paulmck-laptop/ > Signed-off-by: SeongJae Park <sj@kernel.org> > --- > Documentation/RCU/rculist_nulls.rst | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst > index 94a8bfe9f560..4b66e2fd2fb5 100644 > --- a/Documentation/RCU/rculist_nulls.rst > +++ b/Documentation/RCU/rculist_nulls.rst > @@ -18,7 +18,16 @@ to solve following problem. > > Without 'nulls', a typical RCU linked list managing objects which are > allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can use the following > -algorithms: > +algorithms. Following examples assume 'obj' is a pointer to such > +objects, which is having below type. > + > +:: > + > + struct object { > + struct hlist_node obj_node; > + refcount_t refcnt; atomic_t > + unsigned int key; > + }; > > 1) Lookup algorithm > ------------------- > @@ -142,6 +151,9 @@ the beginning. If the object was moved to the same chain, > then the reader doesn't care: It might occasionally > scan the list again without harm. > > +Note that using hlist_nulls means the type of 'obj_node' field of > +'struct object' becomes 'struct hlist_nulls_node'. > + > > 1) lookup algorithm > ------------------- > -- > 2.25.1 >
On Sat, 17 Jun 2023 01:46:16 +0800 Alan Huang <mmpgouride@gmail.com> wrote: > > > 2023年6月16日 02:10，SeongJae Park <sj@kernel.org> 写道： > > > > The type of 'obj' in example code of rculist_nulls.rst is implicit. > > Provide the specific type of it before the example code. > > > > Suggested-by: aul E. McKenney <paulmck@kernel.org> > > Paul E. McKenney Oops, thank you for finding, and sorry, Paul :) > > > Link: https://lore.kernel.org/rcu/43943609-f80c-4b6a-9844-994eef800757@paulmck-laptop/ > > Signed-off-by: SeongJae Park <sj@kernel.org> > > --- > > Documentation/RCU/rculist_nulls.rst | 14 +++++++++++++- > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst > > index 94a8bfe9f560..4b66e2fd2fb5 100644 > > --- a/Documentation/RCU/rculist_nulls.rst > > +++ b/Documentation/RCU/rculist_nulls.rst > > @@ -18,7 +18,16 @@ to solve following problem. > > > > Without 'nulls', a typical RCU linked list managing objects which are > > allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can use the following > > -algorithms: > > +algorithms. Following examples assume 'obj' is a pointer to such > > +objects, which is having below type. > > + > > +:: > > + > > + struct object { > > + struct hlist_node obj_node; > > + refcount_t refcnt; > > atomic_t I just recalled the example code uses atomic_set_release() for this field. Thank you, Alan! I will fix these in the next spin. Thanks, SJ > > > + unsigned int key; > > + }; > > > > 1) Lookup algorithm > > ------------------- > > @@ -142,6 +151,9 @@ the beginning. If the object was moved to the same chain, > > then the reader doesn't care: It might occasionally > > scan the list again without harm. > > > > +Note that using hlist_nulls means the type of 'obj_node' field of > > +'struct object' becomes 'struct hlist_nulls_node'. > > + > > > > 1) lookup algorithm > > ------------------- > > -- > > 2.25.1 > > > >
On Fri, Jun 16, 2023 at 06:54:11PM +0000, SeongJae Park wrote: > On Sat, 17 Jun 2023 01:46:16 +0800 Alan Huang <mmpgouride@gmail.com> wrote: > > > > > > 2023年6月16日 02:10，SeongJae Park <sj@kernel.org> 写道： > > > > > > The type of 'obj' in example code of rculist_nulls.rst is implicit. > > > Provide the specific type of it before the example code. > > > > > > Suggested-by: aul E. McKenney <paulmck@kernel.org> > > > > Paul E. McKenney > > Oops, thank you for finding, and sorry, Paul :) Not a problem, just send new patches and I will replace those currently in -rcu with those new patches. Thanx, Paul > > > Link: https://lore.kernel.org/rcu/43943609-f80c-4b6a-9844-994eef800757@paulmck-laptop/ > > > Signed-off-by: SeongJae Park <sj@kernel.org> > > > --- > > > Documentation/RCU/rculist_nulls.rst | 14 +++++++++++++- > > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst > > > index 94a8bfe9f560..4b66e2fd2fb5 100644 > > > --- a/Documentation/RCU/rculist_nulls.rst > > > +++ b/Documentation/RCU/rculist_nulls.rst > > > @@ -18,7 +18,16 @@ to solve following problem. > > > > > > Without 'nulls', a typical RCU linked list managing objects which are > > > allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can use the following > > > -algorithms: > > > +algorithms. Following examples assume 'obj' is a pointer to such > > > +objects, which is having below type. > > > + > > > +:: > > > + > > > + struct object { > > > + struct hlist_node obj_node; > > > + refcount_t refcnt; > > > > atomic_t > > I just recalled the example code uses atomic_set_release() for this field. > > Thank you, Alan! > > I will fix these in the next spin. > > > Thanks, > SJ > > > > > > + unsigned int key; > > > + }; > > > > > > 1) Lookup algorithm > > > ------------------- > > > @@ -142,6 +151,9 @@ the beginning. If the object was moved to the same chain, > > > then the reader doesn't care: It might occasionally > > > scan the list again without harm. > > > > > > +Note that using hlist_nulls means the type of 'obj_node' field of > > > +'struct object' becomes 'struct hlist_nulls_node'. > > > + > > > > > > 1) lookup algorithm > > > ------------------- > > > -- > > > 2.25.1 > > > > > > >
diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst index 94a8bfe9f560..4b66e2fd2fb5 100644 --- a/Documentation/RCU/rculist_nulls.rst +++ b/Documentation/RCU/rculist_nulls.rst @@ -18,7 +18,16 @@ to solve following problem. Without 'nulls', a typical RCU linked list managing objects which are allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can use the following -algorithms: +algorithms. Following examples assume 'obj' is a pointer to such +objects, which is having below type. + +:: + + struct object { + struct hlist_node obj_node; + refcount_t refcnt; + unsigned int key; + }; 1) Lookup algorithm ------------------- @@ -142,6 +151,9 @@ the beginning. If the object was moved to the same chain, then the reader doesn't care: It might occasionally scan the list again without harm. +Note that using hlist_nulls means the type of 'obj_node' field of +'struct object' becomes 'struct hlist_nulls_node'. + 1) lookup algorithm -------------------
The type of 'obj' in example code of rculist_nulls.rst is implicit. Provide the specific type of it before the example code. Suggested-by: aul E. McKenney <paulmck@kernel.org> Link: https://lore.kernel.org/rcu/43943609-f80c-4b6a-9844-994eef800757@paulmck-laptop/ Signed-off-by: SeongJae Park <sj@kernel.org> --- Documentation/RCU/rculist_nulls.rst | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)