On Mon, Nov 27, 2017 at 01:10:31PM +, Will Deacon wrote:
> break_lock should be annotated (at least) with READ_ONCE/WRITE_ONCE, which
> should prevent that from happening.
This code long predates all that new fangled stuff ;-)
On Mon, Nov 27, 2017 at 02:00:28PM +0100, Martin Schwidefsky wrote:
> I would opt for removing it entirely.
Like said; I'm not opposed to that. I was just explaining where it came
from (before my time might I add) and how its supposed to 'work' :-)
On Mon, Nov 27, 2017 at 02:00:28PM +0100, Martin Schwidefsky wrote:
> On Mon, 27 Nov 2017 12:54:56 +
> Will Deacon wrote:
> > On Mon, Nov 27, 2017 at 01:49:18PM +0100, Martin Schwidefsky wrote:
> > > On Mon, 27 Nov 2017 11:49:48 +
> > > Will Deacon wrote:
> > > > On Wed, Nov 22, 2017 at
On Mon, 27 Nov 2017, Will Deacon wrote:
> Sebastian: could you try the diff below, please? If that fixes s390, then
> we can debate the merits of GENERIC_LOCKBREAK independently of fixing this
> issue.
>
> Thanks,
>
> Will
>
> --->8
>
> diff --git a/kernel/locking/spinlock.c b/kernel/locking/sp
On Mon, 27 Nov 2017 12:54:56 +
Will Deacon wrote:
> Hi Martin,
>
> On Mon, Nov 27, 2017 at 01:49:18PM +0100, Martin Schwidefsky wrote:
> > On Mon, 27 Nov 2017 11:49:48 +
> > Will Deacon wrote:
> > > On Wed, Nov 22, 2017 at 09:22:17PM +0100, Peter Zijlstra wrote:
> > > > On Wed, Nov
Hi Martin,
On Mon, Nov 27, 2017 at 01:49:18PM +0100, Martin Schwidefsky wrote:
> On Mon, 27 Nov 2017 11:49:48 +
> Will Deacon wrote:
> > On Wed, Nov 22, 2017 at 09:22:17PM +0100, Peter Zijlstra wrote:
> > > On Wed, Nov 22, 2017 at 06:26:59PM +, Will Deacon wrote:
> > >
> > > > Now, I c
On Mon, 27 Nov 2017 11:49:48 +
Will Deacon wrote:
> Hi Peter,
>
> On Wed, Nov 22, 2017 at 09:22:17PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 22, 2017 at 06:26:59PM +, Will Deacon wrote:
> >
> > > Now, I can't see what the break_lock is doing here other than causing
> > > problems
Me again...
On Mon, Nov 27, 2017 at 11:49:47AM +, Will Deacon wrote:
> On Wed, Nov 22, 2017 at 09:22:17PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 22, 2017 at 06:26:59PM +, Will Deacon wrote:
> >
> > > Now, I can't see what the break_lock is doing here other than causing
> > > problem
Hi Peter,
On Wed, Nov 22, 2017 at 09:22:17PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 22, 2017 at 06:26:59PM +, Will Deacon wrote:
>
> > Now, I can't see what the break_lock is doing here other than causing
> > problems. Is there a good reason for it, or can you just try removing it
> > alt
On Wed, Nov 22, 2017 at 06:26:59PM +, Will Deacon wrote:
> Now, I can't see what the break_lock is doing here other than causing
> problems. Is there a good reason for it, or can you just try removing it
> altogether? Patch below.
The main use is spin_is_contended(), which in turn ends up use
Hi Sebastian,
On Wed, Nov 22, 2017 at 07:54:54PM +0100, Sebastian Ott wrote:
> On Wed, 22 Nov 2017, Will Deacon wrote:
> > Now, I can't see what the break_lock is doing here other than causing
> > problems. Is there a good reason for it, or can you just try removing it
> > altogether? Patch below.
Hello Will,
On Wed, 22 Nov 2017, Will Deacon wrote:
> Now, I can't see what the break_lock is doing here other than causing
> problems. Is there a good reason for it, or can you just try removing it
> altogether? Patch below.
With your patch applied the system is able to boot again.
I did some qu
Hi Sebastian,
Thanks for the report.
On Wed, Nov 22, 2017 at 06:46:01PM +0100, Sebastian Ott wrote:
> One of my test systems (s390) hangs after boot. One of the cpus is idle
> the other is in arch_spin_relax. Bisect pointed to this one:
>
> a8a217c22116eff6c120d753c9934089fb229af0 is the first b
Hi,
One of my test systems (s390) hangs after boot. One of the cpus is idle
the other is in arch_spin_relax. Bisect pointed to this one:
a8a217c22116eff6c120d753c9934089fb229af0 is the first bad commit
commit a8a217c22116eff6c120d753c9934089fb229af0
Author: Will Deacon
Date: Tue Oct 3 19:25:27
14 matches
Mail list logo
