Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-22 Thread Paul E. McKenney
On Tue, May 22, 2018 at 09:38:13AM -0700, Linus Torvalds wrote: > On Tue, May 22, 2018 at 2:09 AM Roman Penyaev < > roman.peny...@profitbricks.com> wrote: > > > Should I resend current patch with more clear comments about how careful > > caller should be with a leaking pointer? > > No. Even if

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-22 Thread Paul E. McKenney
On Tue, May 22, 2018 at 11:09:16AM +0200, Roman Penyaev wrote: > On Mon, May 21, 2018 at 5:31 PM, Paul E. McKenney > wrote: > > On Mon, May 21, 2018 at 03:50:10PM +0200, Roman Penyaev wrote: > >> On Sun, May 20, 2018 at 2:43 AM, Paul E. McKenney > >>

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-22 Thread Linus Torvalds
On Tue, May 22, 2018 at 2:09 AM Roman Penyaev < roman.peny...@profitbricks.com> wrote: > Should I resend current patch with more clear comments about how careful > caller should be with a leaking pointer? No. Even if we go your way, there is *one* single user, and that one is special and needs

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-22 Thread Paul E. McKenney
On Tue, May 22, 2018 at 11:09:08AM +0200, Roman Penyaev wrote: > On Mon, May 21, 2018 at 5:33 PM, Paul E. McKenney > wrote: > > On Mon, May 21, 2018 at 08:16:59AM -0700, Linus Torvalds wrote: > >> On Mon, May 21, 2018 at 6:51 AM Roman Penyaev < > >>

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-22 Thread Roman Penyaev
On Mon, May 21, 2018 at 5:31 PM, Paul E. McKenney wrote: > On Mon, May 21, 2018 at 03:50:10PM +0200, Roman Penyaev wrote: >> On Sun, May 20, 2018 at 2:43 AM, Paul E. McKenney >> wrote: >> > On Sat, May 19, 2018 at 10:20:48PM +0200, Roman

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-22 Thread Roman Penyaev
On Mon, May 21, 2018 at 5:33 PM, Paul E. McKenney wrote: > On Mon, May 21, 2018 at 08:16:59AM -0700, Linus Torvalds wrote: >> On Mon, May 21, 2018 at 6:51 AM Roman Penyaev < >> roman.peny...@profitbricks.com> wrote: >> >> > No, I continue from the pointer, which I

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-21 Thread Paul E. McKenney
On Mon, May 21, 2018 at 08:16:59AM -0700, Linus Torvalds wrote: > On Mon, May 21, 2018 at 6:51 AM Roman Penyaev < > roman.peny...@profitbricks.com> wrote: > > > No, I continue from the pointer, which I assigned on the previous IO > > in order to send IO fairly and keep load balanced. > > Right.

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-21 Thread Paul E. McKenney
On Mon, May 21, 2018 at 03:50:10PM +0200, Roman Penyaev wrote: > On Sun, May 20, 2018 at 2:43 AM, Paul E. McKenney > wrote: > > On Sat, May 19, 2018 at 10:20:48PM +0200, Roman Penyaev wrote: > >> On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney > >>

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-21 Thread Linus Torvalds
On Mon, May 21, 2018 at 6:51 AM Roman Penyaev < roman.peny...@profitbricks.com> wrote: > No, I continue from the pointer, which I assigned on the previous IO > in order to send IO fairly and keep load balanced. Right. And that's exactly what has both me and Paul nervous. You're no longer in the

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-21 Thread Roman Penyaev
On Sun, May 20, 2018 at 2:43 AM, Paul E. McKenney wrote: > On Sat, May 19, 2018 at 10:20:48PM +0200, Roman Penyaev wrote: >> On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney >> wrote: >> > On Fri, May 18, 2018 at 03:03:48PM +0200, Roman

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-19 Thread Paul E. McKenney
On Sat, May 19, 2018 at 10:20:48PM +0200, Roman Penyaev wrote: > On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney > wrote: > > On Fri, May 18, 2018 at 03:03:48PM +0200, Roman Pen wrote: > >> Function is going to be used in transport over RDMA module > >> in subsequent

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-19 Thread Linus Torvalds
On Sat, May 19, 2018 at 1:25 PM Roman Penyaev < roman.peny...@profitbricks.com> wrote: > Another one list_for_each_entry_rcu()-like macro I am aware of is used in > block/blk-mq-sched.c, is called list_for_each_entry_rcu_rr():

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-19 Thread Linus Torvalds
On Sat, May 19, 2018 at 1:21 PM Roman Penyaev < roman.peny...@profitbricks.com> wrote: > I need -rr behaviour for doing IO load-balancing when I choose next RDMA > connection from the list in order to send a request, i.e. my code is > something like the following: [ incomplete pseudoicode ] >

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-19 Thread Roman Penyaev
On Fri, May 18, 2018 at 6:56 PM, Linus Torvalds wrote: > On Fri, May 18, 2018 at 6:07 AM Roman Pen > wrote: > >> Function is going to be used in transport over RDMA module >> in subsequent patches. > > Does this really merit its own

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-19 Thread Roman Penyaev
On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney wrote: > On Fri, May 18, 2018 at 03:03:48PM +0200, Roman Pen wrote: >> Function is going to be used in transport over RDMA module >> in subsequent patches. >> >> Function returns next element in round-robin fashion, >>

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-19 Thread Paul E. McKenney
On Fri, May 18, 2018 at 03:03:48PM +0200, Roman Pen wrote: > Function is going to be used in transport over RDMA module > in subsequent patches. > > Function returns next element in round-robin fashion, > i.e. head will be skipped. NULL will be returned if list > is observed as empty. > >

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

2018-05-18 Thread Linus Torvalds
On Fri, May 18, 2018 at 6:07 AM Roman Pen wrote: > Function is going to be used in transport over RDMA module > in subsequent patches. Does this really merit its own helper macro in a generic header? It honestly smells more like "just have an inline helper