From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755404AbdIGMkm (ORCPT ); Thu, 7 Sep 2017 08:40:42 -0400 Received: from merlin.infradead.org ([205.233.59.134]:42466 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755228AbdIGMkk (ORCPT ); Thu, 7 Sep 2017 08:40:40 -0400 Date: Thu, 7 Sep 2017 14:40:33 +0200 From: Peter Zijlstra To: Maxime Ripard Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Thomas Petazzoni , Quentin Schulz , Mylene Josserand Subject: Re: mutex_lock issues during poweroff Message-ID: <20170907124033.bmtsam7nizs7gnvv@hirez.programming.kicks-ass.net> References: <20170907121619.uj245cykaxmhsuve@flea.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170907121619.uj245cykaxmhsuve@flea.lan> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 07, 2017 at 02:16:19PM +0200, Maxime Ripard wrote: > One thing worth noting is that we couldn't reproduce the issue with a > 4.13. We can't bisect really easily due to the amount of patches that > we still have on 4.9 and have all been merged since, but it seems like > the bug was fixed (either on purpose or as a side effect), and was > never sent to stable. Looking at the history of kernel/locking/mutex.c > during that window didn't really show anything obvious though. > > If you have any ideas or spot something very wrong, I'd be happy to > hear about. Thanks! Well, we did a _complete_ rewrite of the mutex primitive in v4.10-rc1. Part of the reason for that rewrite was fixing a starvation case, but for that you'd need to actually have contending usage, which you claim not to have. Aside from that I really can't remember any specific issues with the old code (4.9 is such a long time ago). You could try to disable the optimistic spinning code, see if that helps. You did also say you were running on an ARM64, there were a few memory ordering fixes like for example commit: 50972fe78f24 ("locking/osq_lock: Fix osq_lock queue corruption")