Re: [patch V2 11/15] completion: Use simple wait queues

2020-03-20 Thread Davidlohr Bueso 

On Wed, 18 Mar 2020, Thomas Gleixner wrote:


From: Thomas Gleixner 

completion uses a wait_queue_head_t to enqueue waiters.

wait_queue_head_t contains a spinlock_t to protect the list of waiters
which excludes it from being used in truly atomic context on a PREEMPT_RT
enabled kernel.

The spinlock in the wait queue head cannot be replaced by a raw_spinlock
because:

 - wait queues can have custom wakeup callbacks, which acquire other
   spinlock_t locks and have potentially long execution times

 - wake_up() walks an unbounded number of list entries during the wake up
   and may wake an unbounded number of waiters.

For simplicity and performance reasons complete() should be usable on
PREEMPT_RT enabled kernels.

completions do not use custom wakeup callbacks and are usually single
waiter, except for a few corner cases.

Replace the wait queue in the completion with a simple wait queue (swait),
which uses a raw_spinlock_t for protecting the waiter list and therefore is
safe to use inside truly atomic regions on PREEMPT_RT.

There is no semantical or functional change:

 - completions use the exclusive wait mode which is what swait provides

 - complete() wakes one exclusive waiter

 - complete_all() wakes all waiters while holding the lock which protects
   the wait queue against newly incoming waiters. The conversion to swait
   preserves this behaviour.

complete_all() might cause unbound latencies with a large number of waiters
being woken at once, but most complete_all() usage sites are either in
testing or initialization code or have only a really small number of
concurrent waiters which for now does not cause a latency problem. Keep it
simple for now.

The fixup of the warning check in the USB gadget driver is just a straight
forward conversion of the lockless waiter check from one waitqueue type to
the other.

Signed-off-by: Thomas Gleixner 
Cc: Arnd Bergmann 


Reviewed-by: Davidlohr Bueso

Re: [patch V2 11/15] completion: Use simple wait queues

2020-03-20 Thread Christoph Hellwig 
On Fri, Mar 20, 2020 at 10:25:41AM +1100, Julian Calaby wrote:
> > +++ b/drivers/usb/gadget/function/f_fs.c
> > @@ -1703,7 +1703,7 @@ static void ffs_data_put(struct ffs_data
> > pr_info("%s(): freeing\n", __func__);
> > ffs_data_clear(ffs);
> > BUG_ON(waitqueue_active(>ev.waitq) ||
> > -  waitqueue_active(>ep0req_completion.wait) ||
> > +  swait_active(>ep0req_completion.wait) ||
> 
> This looks like some code is reaching deep into the dirty dark corners
> of the completion implementation, should there be some wrapper around
> this to hide that?

Or just remote it entirely..

Re: [patch V2 11/15] completion: Use simple wait queues

2020-03-19 Thread Julian Calaby 
Hi Thomas,

On Thu, Mar 19, 2020 at 7:48 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> completion uses a wait_queue_head_t to enqueue waiters.
>
> wait_queue_head_t contains a spinlock_t to protect the list of waiters
> which excludes it from being used in truly atomic context on a PREEMPT_RT
> enabled kernel.
>
> The spinlock in the wait queue head cannot be replaced by a raw_spinlock
> because:
>
>   - wait queues can have custom wakeup callbacks, which acquire other
> spinlock_t locks and have potentially long execution times
>
>   - wake_up() walks an unbounded number of list entries during the wake up
> and may wake an unbounded number of waiters.
>
> For simplicity and performance reasons complete() should be usable on
> PREEMPT_RT enabled kernels.
>
> completions do not use custom wakeup callbacks and are usually single
> waiter, except for a few corner cases.
>
> Replace the wait queue in the completion with a simple wait queue (swait),
> which uses a raw_spinlock_t for protecting the waiter list and therefore is
> safe to use inside truly atomic regions on PREEMPT_RT.
>
> There is no semantical or functional change:
>
>   - completions use the exclusive wait mode which is what swait provides
>
>   - complete() wakes one exclusive waiter
>
>   - complete_all() wakes all waiters while holding the lock which protects
> the wait queue against newly incoming waiters. The conversion to swait
> preserves this behaviour.
>
> complete_all() might cause unbound latencies with a large number of waiters
> being woken at once, but most complete_all() usage sites are either in
> testing or initialization code or have only a really small number of
> concurrent waiters which for now does not cause a latency problem. Keep it
> simple for now.
>
> The fixup of the warning check in the USB gadget driver is just a straight
> forward conversion of the lockless waiter check from one waitqueue type to
> the other.
>
> Signed-off-by: Thomas Gleixner 
> Cc: Arnd Bergmann 
> ---
> V2: Split out the orinoco and usb gadget parts and amended change log
> ---
>  drivers/usb/gadget/function/f_fs.c |2 +-
>  include/linux/completion.h |8 
>  kernel/sched/completion.c  |   36 
> +++-
>  3 files changed, 24 insertions(+), 22 deletions(-)
>
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -1703,7 +1703,7 @@ static void ffs_data_put(struct ffs_data
> pr_info("%s(): freeing\n", __func__);
> ffs_data_clear(ffs);
> BUG_ON(waitqueue_active(>ev.waitq) ||
> -  waitqueue_active(>ep0req_completion.wait) ||
> +  swait_active(>ep0req_completion.wait) ||

This looks like some code is reaching deep into the dirty dark corners
of the completion implementation, should there be some wrapper around
this to hide that?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [patch V2 11/15] completion: Use simple wait queues

2020-03-19 Thread Linus Torvalds 
On Wed, Mar 18, 2020 at 1:47 PM Thomas Gleixner  wrote:
>
> There is no semantical or functional change:

Ack, with just the explanation, I'm no longer objecting to this.

Plus you fixed and cleaned up the odd usb gadget code separately
(well, most of it).

  Linus

Re: [patch V2 11/15] completion: Use simple wait queues

2020-03-19 Thread Greg Kroah-Hartman 
On Wed, Mar 18, 2020 at 09:43:13PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner 
> 
> completion uses a wait_queue_head_t to enqueue waiters.
> 
> wait_queue_head_t contains a spinlock_t to protect the list of waiters
> which excludes it from being used in truly atomic context on a PREEMPT_RT
> enabled kernel.
> 
> The spinlock in the wait queue head cannot be replaced by a raw_spinlock
> because:
> 
>   - wait queues can have custom wakeup callbacks, which acquire other
> spinlock_t locks and have potentially long execution times
> 
>   - wake_up() walks an unbounded number of list entries during the wake up
> and may wake an unbounded number of waiters.
> 
> For simplicity and performance reasons complete() should be usable on
> PREEMPT_RT enabled kernels.
> 
> completions do not use custom wakeup callbacks and are usually single
> waiter, except for a few corner cases.
> 
> Replace the wait queue in the completion with a simple wait queue (swait),
> which uses a raw_spinlock_t for protecting the waiter list and therefore is
> safe to use inside truly atomic regions on PREEMPT_RT.
> 
> There is no semantical or functional change:
> 
>   - completions use the exclusive wait mode which is what swait provides
> 
>   - complete() wakes one exclusive waiter
> 
>   - complete_all() wakes all waiters while holding the lock which protects
> the wait queue against newly incoming waiters. The conversion to swait
> preserves this behaviour.
> 
> complete_all() might cause unbound latencies with a large number of waiters
> being woken at once, but most complete_all() usage sites are either in
> testing or initialization code or have only a really small number of
> concurrent waiters which for now does not cause a latency problem. Keep it
> simple for now.
> 
> The fixup of the warning check in the USB gadget driver is just a straight
> forward conversion of the lockless waiter check from one waitqueue type to
> the other.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Arnd Bergmann 
> ---
> V2: Split out the orinoco and usb gadget parts and amended change log
> ---
>  drivers/usb/gadget/function/f_fs.c |2 +-
>  include/linux/completion.h |8 
>  kernel/sched/completion.c  |   36 
> +++-
>  3 files changed, 24 insertions(+), 22 deletions(-)

For USB portion:

Reviewed-by: Greg Kroah-Hartman

Re: [patch V2 11/15] completion: Use simple wait queues

2020-03-18 Thread Thomas Gleixner 
Joel,

Joel Fernandes  writes:
> On Wed, Mar 18, 2020 at 09:43:13PM +0100, Thomas Gleixner wrote:
>> The spinlock in the wait queue head cannot be replaced by a raw_spinlock
>> because:
>> 
>>   - wait queues can have custom wakeup callbacks, which acquire other
>> spinlock_t locks and have potentially long execution times
>
> Cool, makes sense.
>
>>   - wake_up() walks an unbounded number of list entries during the wake up
>> and may wake an unbounded number of waiters.
>
> Just to clarify here, wake_up() will really wake up just 1 waiter if all the
> waiters on the queue are exclusive right? So in such scenario at least, the
> "unbounded number of waiters" would not be an issue if everything waiting was
> exclusive and waitqueue with wake_up() was used. Please correct me if I'm
> wrong about that though.

Correct.

> So the main reasons to avoid waitqueue in favor of swait (as you mentioned)
> would be the sleep-while-atomic issue in truly atomic context on RT, and the
> fact that callbacks can take a long time.

Yes.

Thanks,

tglx

Re: [patch V2 11/15] completion: Use simple wait queues

2020-03-18 Thread Joel Fernandes 
Hi Thomas,

On Wed, Mar 18, 2020 at 09:43:13PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner 
> 
> completion uses a wait_queue_head_t to enqueue waiters.
> 
> wait_queue_head_t contains a spinlock_t to protect the list of waiters
> which excludes it from being used in truly atomic context on a PREEMPT_RT
> enabled kernel.
> 
> The spinlock in the wait queue head cannot be replaced by a raw_spinlock
> because:
> 
>   - wait queues can have custom wakeup callbacks, which acquire other
> spinlock_t locks and have potentially long execution times

Cool, makes sense.

>   - wake_up() walks an unbounded number of list entries during the wake up
> and may wake an unbounded number of waiters.

Just to clarify here, wake_up() will really wake up just 1 waiter if all the
waiters on the queue are exclusive right? So in such scenario at least, the
"unbounded number of waiters" would not be an issue if everything waiting was
exclusive and waitqueue with wake_up() was used. Please correct me if I'm
wrong about that though.

So the main reasons to avoid waitqueue in favor of swait (as you mentioned)
would be the sleep-while-atomic issue in truly atomic context on RT, and the
fact that callbacks can take a long time.

> 
> For simplicity and performance reasons complete() should be usable on
> PREEMPT_RT enabled kernels.
> 
> completions do not use custom wakeup callbacks and are usually single
> waiter, except for a few corner cases.
> 
> Replace the wait queue in the completion with a simple wait queue (swait),
> which uses a raw_spinlock_t for protecting the waiter list and therefore is
> safe to use inside truly atomic regions on PREEMPT_RT.
> 
> There is no semantical or functional change:
> 
>   - completions use the exclusive wait mode which is what swait provides
> 
>   - complete() wakes one exclusive waiter
> 
>   - complete_all() wakes all waiters while holding the lock which protects
> the wait queue against newly incoming waiters. The conversion to swait
> preserves this behaviour.
> 
> complete_all() might cause unbound latencies with a large number of waiters
> being woken at once, but most complete_all() usage sites are either in
> testing or initialization code or have only a really small number of
> concurrent waiters which for now does not cause a latency problem. Keep it
> simple for now.
> 
> The fixup of the warning check in the USB gadget driver is just a straight
> forward conversion of the lockless waiter check from one waitqueue type to
> the other.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Arnd Bergmann 

Reviewed-by: Joel Fernandes (Google) 

thanks,

 - Joel


> ---
> V2: Split out the orinoco and usb gadget parts and amended change log
> ---
>  drivers/usb/gadget/function/f_fs.c |2 +-
>  include/linux/completion.h |8 
>  kernel/sched/completion.c  |   36 
> +++-
>  3 files changed, 24 insertions(+), 22 deletions(-)
> 
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -1703,7 +1703,7 @@ static void ffs_data_put(struct ffs_data
>   pr_info("%s(): freeing\n", __func__);
>   ffs_data_clear(ffs);
>   BUG_ON(waitqueue_active(>ev.waitq) ||
> -waitqueue_active(>ep0req_completion.wait) ||
> +swait_active(>ep0req_completion.wait) ||
>  waitqueue_active(>wait));
>   destroy_workqueue(ffs->io_completion_wq);
>   kfree(ffs->dev_name);
> --- a/include/linux/completion.h
> +++ b/include/linux/completion.h
> @@ -9,7 +9,7 @@
>   * See kernel/sched/completion.c for details.
>   */
>  
> -#include 
> +#include 
>  
>  /*
>   * struct completion - structure used to maintain state for a "completion"
> @@ -25,7 +25,7 @@
>   */
>  struct completion {
>   unsigned int done;
> - wait_queue_head_t wait;
> + struct swait_queue_head wait;
>  };
>  
>  #define init_completion_map(x, m) __init_completion(x)
> @@ -34,7 +34,7 @@ static inline void complete_acquire(stru
>  static inline void complete_release(struct completion *x) {}
>  
>  #define COMPLETION_INITIALIZER(work) \
> - { 0, __WAIT_QUEUE_HEAD_INITIALIZER((work).wait) }
> + { 0, __SWAIT_QUEUE_HEAD_INITIALIZER((work).wait) }
>  
>  #define COMPLETION_INITIALIZER_ONSTACK_MAP(work, map) \
>   (*({ init_completion_map(&(work), &(map)); &(work); }))
> @@ -85,7 +85,7 @@ static inline void complete_release(stru
>  static inline void __init_completion(struct completion *x)
>  {
>   x->done = 0;
> - init_waitqueue_head(>wait);
> + init_swait_queue_head(>wait);
>  }
>  
>  /**
> --- a/kernel/sched/completion.c
> +++ b/kernel/sched/completion.c
> @@ -29,12 +29,12 @@ void complete(struct completion *x)
>  {
>   unsigned long flags;
>  
> - spin_lock_irqsave(>wait.lock, flags);
> + raw_spin_lock_irqsave(>wait.lock, flags);
>  
>   if (x->done != UINT_MAX)
>

Re: [patch V2 11/15] completion: Use simple wait queues

2020-03-18 Thread Logan Gunthorpe 



On 2020-03-18 2:43 p.m., Thomas Gleixner wrote:
> There is no semantical or functional change:
> 
>   - completions use the exclusive wait mode which is what swait provides
> 
>   - complete() wakes one exclusive waiter
> 
>   - complete_all() wakes all waiters while holding the lock which protects
> the wait queue against newly incoming waiters. The conversion to swait
> preserves this behaviour.
> 
> complete_all() might cause unbound latencies with a large number of waiters
> being woken at once, but most complete_all() usage sites are either in
> testing or initialization code or have only a really small number of
> concurrent waiters which for now does not cause a latency problem. Keep it
> simple for now.

Seems like it would be worth adding a note for this to the
complete_all() doc string. Otherwise developers will not likely find out
about this issue and may not keep it as simple as you'd like.

Logan

[patch V2 11/15] completion: Use simple wait queues

2020-03-18 Thread Thomas Gleixner 
From: Thomas Gleixner 

completion uses a wait_queue_head_t to enqueue waiters.

wait_queue_head_t contains a spinlock_t to protect the list of waiters
which excludes it from being used in truly atomic context on a PREEMPT_RT
enabled kernel.

The spinlock in the wait queue head cannot be replaced by a raw_spinlock
because:

  - wait queues can have custom wakeup callbacks, which acquire other
spinlock_t locks and have potentially long execution times

  - wake_up() walks an unbounded number of list entries during the wake up
and may wake an unbounded number of waiters.

For simplicity and performance reasons complete() should be usable on
PREEMPT_RT enabled kernels.

completions do not use custom wakeup callbacks and are usually single
waiter, except for a few corner cases.

Replace the wait queue in the completion with a simple wait queue (swait),
which uses a raw_spinlock_t for protecting the waiter list and therefore is
safe to use inside truly atomic regions on PREEMPT_RT.

There is no semantical or functional change:

  - completions use the exclusive wait mode which is what swait provides

  - complete() wakes one exclusive waiter

  - complete_all() wakes all waiters while holding the lock which protects
the wait queue against newly incoming waiters. The conversion to swait
preserves this behaviour.

complete_all() might cause unbound latencies with a large number of waiters
being woken at once, but most complete_all() usage sites are either in
testing or initialization code or have only a really small number of
concurrent waiters which for now does not cause a latency problem. Keep it
simple for now.

The fixup of the warning check in the USB gadget driver is just a straight
forward conversion of the lockless waiter check from one waitqueue type to
the other.

Signed-off-by: Thomas Gleixner 
Cc: Arnd Bergmann 
---
V2: Split out the orinoco and usb gadget parts and amended change log
---
 drivers/usb/gadget/function/f_fs.c |2 +-
 include/linux/completion.h |8 
 kernel/sched/completion.c  |   36 +++-
 3 files changed, 24 insertions(+), 22 deletions(-)

--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1703,7 +1703,7 @@ static void ffs_data_put(struct ffs_data
pr_info("%s(): freeing\n", __func__);
ffs_data_clear(ffs);
BUG_ON(waitqueue_active(>ev.waitq) ||
-  waitqueue_active(>ep0req_completion.wait) ||
+  swait_active(>ep0req_completion.wait) ||
   waitqueue_active(>wait));
destroy_workqueue(ffs->io_completion_wq);
kfree(ffs->dev_name);
--- a/include/linux/completion.h
+++ b/include/linux/completion.h
@@ -9,7 +9,7 @@
  * See kernel/sched/completion.c for details.
  */
 
-#include 
+#include 
 
 /*
  * struct completion - structure used to maintain state for a "completion"
@@ -25,7 +25,7 @@
  */
 struct completion {
unsigned int done;
-   wait_queue_head_t wait;
+   struct swait_queue_head wait;
 };
 
 #define init_completion_map(x, m) __init_completion(x)
@@ -34,7 +34,7 @@ static inline void complete_acquire(stru
 static inline void complete_release(struct completion *x) {}
 
 #define COMPLETION_INITIALIZER(work) \
-   { 0, __WAIT_QUEUE_HEAD_INITIALIZER((work).wait) }
+   { 0, __SWAIT_QUEUE_HEAD_INITIALIZER((work).wait) }
 
 #define COMPLETION_INITIALIZER_ONSTACK_MAP(work, map) \
(*({ init_completion_map(&(work), &(map)); &(work); }))
@@ -85,7 +85,7 @@ static inline void complete_release(stru
 static inline void __init_completion(struct completion *x)
 {
x->done = 0;
-   init_waitqueue_head(>wait);
+   init_swait_queue_head(>wait);
 }
 
 /**
--- a/kernel/sched/completion.c
+++ b/kernel/sched/completion.c
@@ -29,12 +29,12 @@ void complete(struct completion *x)
 {
unsigned long flags;
 
-   spin_lock_irqsave(>wait.lock, flags);
+   raw_spin_lock_irqsave(>wait.lock, flags);
 
if (x->done != UINT_MAX)
x->done++;
-   __wake_up_locked(>wait, TASK_NORMAL, 1);
-   spin_unlock_irqrestore(>wait.lock, flags);
+   swake_up_locked(>wait);
+   raw_spin_unlock_irqrestore(>wait.lock, flags);
 }
 EXPORT_SYMBOL(complete);
 
@@ -58,10 +58,12 @@ void complete_all(struct completion *x)
 {
unsigned long flags;
 
-   spin_lock_irqsave(>wait.lock, flags);
+   WARN_ON(irqs_disabled());
+
+   raw_spin_lock_irqsave(>wait.lock, flags);
x->done = UINT_MAX;
-   __wake_up_locked(>wait, TASK_NORMAL, 0);
-   spin_unlock_irqrestore(>wait.lock, flags);
+   swake_up_all_locked(>wait);
+   raw_spin_unlock_irqrestore(>wait.lock, flags);
 }
 EXPORT_SYMBOL(complete_all);
 
@@ -70,20 +72,20 @@ do_wait_for_common(struct completion *x,
   long (*action)(long), long timeout, int state)
 {
if (!x->done) {
-