On Fri, Jul 28, 2017 at 7:05 AM, Vlastimil Babka wrote:
> On 07/28/2017 11:30 AM, Peter Zijlstra wrote:
>> On Fri, Jul 28, 2017 at 09:45:16AM +0200, Vlastimil Babka wrote:
>>> [+CC PeterZ]
>>>
>>> On 07/27/2017 06:46 PM, Dima Zavin wrote:
>>>> In
_unlock_irq+0x2d/0x60
? trace_hardirqs_on_caller+0x136/0x1d0
? entry_SYSCALL_64_fastpath+0x5/0xad
? do_syscall_64+0x27/0x350
? SyS_clone+0x19/0x20
? do_syscall_64+0x60/0x350
? entry_SYSCALL64_slow_path+0x25/0x25
Reported-by: Cliff Spradlin
Signed-off-by: Dima Zavin
---
v3:
On Sun, Jul 30, 2017 at 9:01 PM, Dima Zavin wrote:
> In codepaths that use the begin/retry interface for reading
> mems_allowed_seq with irqs disabled, there exists a race condition that
> stalls the patch process after only modifying a subset of the
> static_branch call sites.
>
On Mon, Jul 31, 2017 at 1:02 AM, Vlastimil Babka wrote:
> On 07/31/2017 06:01 AM, Dima Zavin wrote:
>> In codepaths that use the begin/retry interface for reading
>> mems_allowed_seq with irqs disabled, there exists a race condition that
>> stalls the patch process after on
On Mon, Jul 31, 2017 at 6:33 AM, Peter Zijlstra wrote:
> On Mon, Jul 31, 2017 at 03:04:06PM +0200, Paolo Bonzini wrote:
>> - key->enabled cannot go from 0 to nonzero outside jump_label_mutex.
>> For this reason the atomic_try_cmpxchg is unnecessary.
>
> Agreed, the only reason was the implied barr
_fork+0xe7/0x6c0
? _raw_spin_unlock_irq+0x2d/0x60
? trace_hardirqs_on_caller+0x136/0x1d0
? entry_SYSCALL_64_fastpath+0x5/0xad
? do_syscall_64+0x27/0x350
? SyS_clone+0x19/0x20
? do_syscall_64+0x60/0x350
? entry_SYSCALL64_slow_path+0x25/0x25
Reported-by: Cliff Spradlin
Signed-off-by: Dima Zav
On Wed, Jul 26, 2017 at 10:02 AM, Christopher Lameter wrote:
> On Wed, 26 Jul 2017, Dima Zavin wrote:
>
>> The fix is to cache the value that's returned by cpusets_enabled() at the
>> top of the loop, and only operate on the seqlock (both begin and retry) if
>> it was
_fork+0xe7/0x6c0
? _raw_spin_unlock_irq+0x2d/0x60
? trace_hardirqs_on_caller+0x136/0x1d0
? entry_SYSCALL_64_fastpath+0x5/0xad
? do_syscall_64+0x27/0x350
? SyS_clone+0x19/0x20
? do_syscall_64+0x60/0x350
? entry_SYSCALL64_slow_path+0x25/0x25
Reported-by: Cliff Spradlin
Signed-off-by: Dim
On Thu, Jul 27, 2017 at 12:48 PM, Andrew Morton
wrote:
> On Thu, 27 Jul 2017 09:46:08 -0700 Dima Zavin wrote:
>
>> In codepaths that use the begin/retry interface for reading
>> mems_allowed_seq with irqs disabled, there exists a race condition that
>> stalls the
On Thu, Jul 27, 2017 at 12:51 PM, Andrew Morton
wrote:
> On Thu, 27 Jul 2017 09:46:08 -0700 Dima Zavin wrote:
>
>> - Applied on top of v4.12 since one of the callers in page_alloc.c changed.
>>Still only tested on v4.9.36 and compile tested against v4.12.
>
> That&#x
On Fri, Jul 28, 2017 at 12:45 AM, Vlastimil Babka wrote:
> [+CC PeterZ]
>
> On 07/27/2017 06:46 PM, Dima Zavin wrote:
>> In codepaths that use the begin/retry interface for reading
>> mems_allowed_seq with irqs disabled, there exists a race condition that
>> stalls t
11 matches
Mail list logo
