Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938625AbcKXLxI (ORCPT ); Thu, 24 Nov 2016 06:53:08 -0500 Received: from mail-io0-f180.google.com ([209.85.223.180]:33875 "EHLO mail-io0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936310AbcKXLxF (ORCPT ); Thu, 24 Nov 2016 06:53:05 -0500 MIME-Version: 1.0 X-Originating-IP: [2a02:168:56b5:0:ac27:b86c:7764:9429] In-Reply-To: <20161124114007.GE3092@twins.programming.kicks-ass.net> References: <1479900325-28358-1-git-send-email-nhaehnle@gmail.com> <20161123140336.GU3092@twins.programming.kicks-ass.net> <20161123142525.ns2pkyp4bo2sa5z2@phenom.ffwll.local> <20161124114007.GE3092@twins.programming.kicks-ass.net> From: Daniel Vetter Date: Thu, 24 Nov 2016 12:52:25 +0100 X-Google-Sender-Auth: m6Dc-ZEki3jWlGnxGMVXHFsHq9w Message-ID: Subject: Re: [PATCH 1/4] locking/ww_mutex: Fix a deadlock affecting ww_mutexes To: Peter Zijlstra Cc: =?UTF-8?Q?Nicolai_H=C3=A4hnle?= , =?UTF-8?Q?Nicolai_H=C3=A4hnle?= , Linux Kernel Mailing List , stable , Ingo Molnar , dri-devel , Maarten Lankhorst Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1269 Lines: 29 On Thu, Nov 24, 2016 at 12:40 PM, Peter Zijlstra wrote: > >> I do believe we can win a bit by keeping the wait list sorted, if we also >> make sure that waiters don't add themselves in the first place if they see >> that a deadlock situation cannot be avoided. >> >> I will probably want to extend struct mutex_waiter with ww_mutex-specific >> fields to facilitate this (i.e. ctx pointer, perhaps stamp as well to reduce >> pointer-chasing). That should be fine since it lives on the stack. > > Right, shouldn't be a problem I think. > > The only 'problem' I can see with using that is that its possible to mix > ww and !ww waiters through ww_mutex_lock(.ctx = NULL). This makes the > list order somewhat tricky. > > Ideally we'd remove that feature, although I see its actually used quite > a bit :/ I guess we could create a small fake acquire_ctx for single-lock paths. That way callers still don't need to deal with having an explicit ctx, but we can assume the timestamp (for ensuring fairness) is available for all cases. Otherwise there's indeed a problem with correctly (well fairly) interleaving ctx and non-ctx lockers I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch