I have confirmed the theory using a sample code like :
spin_lock();
spin_lock();
cond_resched_lock();
spin_unlock();
spin_unlock();
Also, the following patch solves the problem for me.
8>-
sched: Fix ___might_sleep preempt count checks
On 30/03/17 17:40, Suzuki K Poulose wrote:
On 30/03/17 16:41, Marc Zyngier wrote:
On 30/03/17 16:29, Mark Rutland wrote:
On Thu, Mar 30, 2017 at 03:31:12PM +0100, Mark Rutland wrote:
Hi,
I'm seeing the splat below when running KVM on an arm64 host with
CONFIG_DEBUG_ATOMIC_SLEEP and
On 30/03/17 16:41, Marc Zyngier wrote:
On 30/03/17 16:29, Mark Rutland wrote:
On Thu, Mar 30, 2017 at 03:31:12PM +0100, Mark Rutland wrote:
Hi,
I'm seeing the splat below when running KVM on an arm64 host with
CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_LOCKDEP enabled.
I saw this on v4.11-rc1, and
On 30/03/17 16:29, Mark Rutland wrote:
> On Thu, Mar 30, 2017 at 03:31:12PM +0100, Mark Rutland wrote:
>> Hi,
>>
>> I'm seeing the splat below when running KVM on an arm64 host with
>> CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_LOCKDEP enabled.
>>
>> I saw this on v4.11-rc1, and I can reproduce the
On Thu, Mar 30, 2017 at 03:31:12PM +0100, Mark Rutland wrote:
> Hi,
>
> I'm seeing the splat below when running KVM on an arm64 host with
> CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_LOCKDEP enabled.
>
> I saw this on v4.11-rc1, and I can reproduce the problem on the current
> kvmarm master branch
Hi,
I'm seeing the splat below when running KVM on an arm64 host with
CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_LOCKDEP enabled.
I saw this on v4.11-rc1, and I can reproduce the problem on the current
kvmarm master branch (563e2f5daa66fbc1).
I've hacked noinlines into arch/arm/kvm/mmu.c in an
