On 2019-07-02 06:40:28 [-0500], Corey Minyard wrote:
> On Tue, Jul 02, 2019 at 10:35:36AM +0200, Sebastian Andrzej Siewior wrote:
> > On 2019-07-02 09:04:18 [+0200], Kurt Kanzenbach wrote:
> > > > In fact, my system doesn't boot with this commit in 5.0-rt.
> > > >
> > > > If I revert 90e1b18eba2ae4
On Tue, Jul 02, 2019 at 10:35:36AM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-07-02 09:04:18 [+0200], Kurt Kanzenbach wrote:
> > > In fact, my system doesn't boot with this commit in 5.0-rt.
> > >
> > > If I revert 90e1b18eba2ae4a729 ("swait: Delete the task from after a
> > > wakeup occured
On 2019-07-02 09:04:18 [+0200], Kurt Kanzenbach wrote:
> > In fact, my system doesn't boot with this commit in 5.0-rt.
> >
> > If I revert 90e1b18eba2ae4a729 ("swait: Delete the task from after a
> > wakeup occured") the machine boots again.
> >
> > Sebastian, I think that's a bad commit, please re
Hi,
On Mon, Jul 01, 2019 at 05:28:25PM -0400, Steven Rostedt wrote:
> On Mon, 1 Jul 2019 17:13:33 -0400
> Steven Rostedt wrote:
>
> > On Mon, 1 Jul 2019 17:06:02 -0400
> > Steven Rostedt wrote:
> >
> > > On Mon, 1 Jul 2019 15:43:25 -0500
> > > Corey Minyard wrote:
> > >
> > >
> > > > I show tha
On Mon, Jul 01, 2019 at 05:28:25PM -0400, Steven Rostedt wrote:
> On Mon, 1 Jul 2019 17:13:33 -0400
> Steven Rostedt wrote:
>
> > On Mon, 1 Jul 2019 17:06:02 -0400
> > Steven Rostedt wrote:
> >
> > > On Mon, 1 Jul 2019 15:43:25 -0500
> > > Corey Minyard wrote:
> > >
> > >
> > > > I show th
On Mon, 1 Jul 2019 17:13:33 -0400
Steven Rostedt wrote:
> On Mon, 1 Jul 2019 17:06:02 -0400
> Steven Rostedt wrote:
>
> > On Mon, 1 Jul 2019 15:43:25 -0500
> > Corey Minyard wrote:
> >
> >
> > > I show that patch is already applied at
> > >
> > > 1921ea799b7dc561c97185538100271d88ee47
On Mon, 1 Jul 2019 17:06:02 -0400
Steven Rostedt wrote:
> On Mon, 1 Jul 2019 15:43:25 -0500
> Corey Minyard wrote:
>
>
> > I show that patch is already applied at
> >
> > 1921ea799b7dc561c97185538100271d88ee47db
> > sched/completion: Fix a lockup in wait_for_completion()
> >
> > git
On Mon, 1 Jul 2019 15:43:25 -0500
Corey Minyard wrote:
> I show that patch is already applied at
>
> 1921ea799b7dc561c97185538100271d88ee47db
> sched/completion: Fix a lockup in wait_for_completion()
>
> git describe --contains 1921ea799b7dc561c97185538100271d88ee47db
> v4.19.37-rt20~1
On Mon, Jul 01, 2019 at 04:18:40PM -0400, Steven Rostedt wrote:
> On Mon, 1 Jul 2019 14:09:49 -0500
> Corey Minyard wrote:
>
> > On Fri, Jun 28, 2019 at 09:49:03PM -0400, Steven Rostedt wrote:
> > > On Fri, 10 May 2019 12:33:18 +0200
> > > Sebastian Andrzej Siewior wrote:
>
> > >
> > > When I
On Fri, Jun 28, 2019 at 09:49:03PM -0400, Steven Rostedt wrote:
> On Fri, 10 May 2019 12:33:18 +0200
> Sebastian Andrzej Siewior wrote:
>
> > On 2019-05-09 14:33:20 [-0500], miny...@acm.org wrote:
> > > From: Corey Minyard
> > >
> > > The function call do_wait_for_common() has a race condition
On Fri, 10 May 2019 12:33:18 +0200
Sebastian Andrzej Siewior wrote:
> On 2019-05-09 14:33:20 [-0500], miny...@acm.org wrote:
> > From: Corey Minyard
> >
> > The function call do_wait_for_common() has a race condition that
> > can result in lockups waiting for completions. Adding the thread
> >
On Thu, May 09, 2019 at 06:19:25PM +0200, Sebastian Andrzej Siewior wrote:
> One question for the upstream completion implementation:
> completion_done() returns true if there are no waiters. It acquires the
> wait.lock to ensure that complete()/complete_all() is done. However,
> once complete rele
On Tue, May 14, 2019 at 05:36:47PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-05-14 07:13:50 [-0500], Corey Minyard wrote:
> > > Corey, would it make any change which waiter is going to be woken up?
> >
> > In the application that found this, the wake order probably isn't
> > relevant.
>
>
On 2019-05-14 07:13:50 [-0500], Corey Minyard wrote:
> > Corey, would it make any change which waiter is going to be woken up?
>
> In the application that found this, the wake order probably isn't
> relevant.
what I expected.
> For other applications, I really doubt that very many are using mult
On 2019-05-14 13:35:38 [+0200], Peter Zijlstra wrote:
> On Tue, May 14, 2019 at 11:12:19AM +0200, Sebastian Andrzej Siewior wrote:
> > On 2019-05-14 10:43:56 [+0200], Peter Zijlstra wrote:
> > > Now.. that will fix it, but I think it is also wrong.
> > >
> > > The problem being that it violates FI
On Tue, May 14, 2019 at 11:12:19AM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-05-14 10:43:56 [+0200], Peter Zijlstra wrote:
> > Now.. that will fix it, but I think it is also wrong.
> >
> > The problem being that it violates FIFO, something that might be more
> > important on -RT than elsew
On Tue, May 14, 2019 at 11:12:19AM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-05-14 10:43:56 [+0200], Peter Zijlstra wrote:
> > Now.. that will fix it, but I think it is also wrong.
> >
> > The problem being that it violates FIFO, something that might be more
> > important on -RT than elsew
On 2019-05-14 10:43:56 [+0200], Peter Zijlstra wrote:
> Now.. that will fix it, but I think it is also wrong.
>
> The problem being that it violates FIFO, something that might be more
> important on -RT than elsewhere.
Wouldn't -RT be more about waking the task with the highest priority
instead t
On Thu, May 09, 2019 at 06:19:25PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-05-08 15:57:28 [-0500], miny...@acm.org wrote:
> > kernel/sched/completion.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/sched/completion.c b/kernel/sched/comple
On 2019-05-10 07:08:24 [-0500], Corey Minyard wrote:
> Thanks a bunch. Do I need to do anything for backports? I'm pretty
> sure this goes back to 4.4.
No, you don't. I plan to release a new 5.0-RT today. Then the stable
maintainer will pick it at once they get to it.
4.4 is maintained by Daniel
On Fri, May 10, 2019 at 12:33:18PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-05-09 14:33:20 [-0500], miny...@acm.org wrote:
> > From: Corey Minyard
> >
> > The function call do_wait_for_common() has a race condition that
> > can result in lockups waiting for completions. Adding the threa
On 2019-05-09 14:33:20 [-0500], miny...@acm.org wrote:
> From: Corey Minyard
>
> The function call do_wait_for_common() has a race condition that
> can result in lockups waiting for completions. Adding the thread
> to (and removing the thread from) the wait queue for the completion
> is done out
On Thu, 9 May 2019 14:33:20 -0500
miny...@acm.org wrote:
> From: Corey Minyard
>
> The function call do_wait_for_common() has a race condition that
> can result in lockups waiting for completions. Adding the thread
> to (and removing the thread from) the wait queue for the completion
> is done
From: Corey Minyard
The function call do_wait_for_common() has a race condition that
can result in lockups waiting for completions. Adding the thread
to (and removing the thread from) the wait queue for the completion
is done outside the do loop in that function. However, if the thread
is woken
On Thu, May 09, 2019 at 06:19:25PM +0200, Sebastian Andrzej Siewior wrote:
> Please:
> - add some RT developers on Cc:
> - add lkml
> - use [PATCH RT] instead just [PATCH] so it is visible that you target
>the RT tree.
Will do. I'll add your diagram below, too.
>
> On 2019-05-08 15:57:28
Please:
- add some RT developers on Cc:
- add lkml
- use [PATCH RT] instead just [PATCH] so it is visible that you target
the RT tree.
On 2019-05-08 15:57:28 [-0500], miny...@acm.org wrote:
> From: Corey Minyard
>
> The function call do_wait_for_common() has a race condition that
> can res
26 matches
Mail list logo
