Received: by 10.223.185.116 with SMTP id b49csp1108362wrg; Sat, 3 Mar 2018 15:48:56 -0800 (PST) X-Google-Smtp-Source: AG47ELvFaTBEwSV/HZUI9yOiZnj4caGWY6REJ1einoVSWeoW3Isu3zxIDioFHYcMqjYz4Vfpe+TZ X-Received: by 10.99.99.66 with SMTP id x63mr8506874pgb.421.1520120936701; Sat, 03 Mar 2018 15:48:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520120936; cv=none; d=google.com; s=arc-20160816; b=XnyfJChgK5lLA6JYrASqn4xULC2XTi3QuISrD0/COjsQ8EVQjS1YvuHdk9YKMgmuLd eN/1kIItNXlu0s1l+kWB2Ooj75q6x+iffbVYvR6azVmXnh/iRt17ZFkpyiTjWZaRgZj4 WVn7DQ2qMcPHsgqqntRCo7owEX2etG8j0QNf+fjTY9kax+2EwK081mzjQew+OD0bI4up Osq3xfhKT6HlRFBb+C6SmJPQ8nts9qwxIoDjYgAPFZGsxrmL4q4duqEYj3TV8WlzWp8s +VhpcEUDYdyPddNhOBzeP4e0OJL1e7kVeCoU9yhwgdbpZK4xvCj9WhXYVHjUU5VwS2z7 qR2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :spamdiagnosticmetadata:spamdiagnosticoutput:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=9bmtbw0khGlxvFriu5WTIGaddUmj0RTo1cGPtld7zD0=; b=vEQLsG2fK95TANP+14MPBuAVrrZFu2EzpBzYNQSQvQN56QgTl3FNiJYB8TH7wY4DHm NCyTzsGzjj4GlDhRlMVlwOJwVEvhzWZOSbr3AXCcie0Bi69vYY7n7EdBX+Nu44TCJD/j FFNjH0AyUNoTgsavp54jNwS0FDY+/T4qPtY5QpsOsgCSkM+l4F7Y1BG8eLzsPTvxzdmn LzQUYSaD5HF3TITnLF9SmuzdEczbnFPTtBa6D9hr3Yu1vRGyhDe42i5ltEbN4SIRosDj jTWKJH+M277f5rYL7kXVTIps0BgVrM+GaWqJu5AUSvqTwJFM10zx/M6ru3lt/Cwb9u42 0wWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microsoft.com header.s=selector1 header.b=TVdYFLc3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c23-v6si6761037plz.794.2018.03.03.15.48.43; Sat, 03 Mar 2018 15:48:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@microsoft.com header.s=selector1 header.b=TVdYFLc3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934047AbeCCXrt (ORCPT + 99 others); Sat, 3 Mar 2018 18:47:49 -0500 Received: from mail-by2nam03on0128.outbound.protection.outlook.com ([104.47.42.128]:37280 "EHLO NAM03-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933058AbeCCWeC (ORCPT ); Sat, 3 Mar 2018 17:34:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9bmtbw0khGlxvFriu5WTIGaddUmj0RTo1cGPtld7zD0=; b=TVdYFLc3gKTSu+4Yb0Glo4zk95zwhi0H1oM8C5ahHQP7veDbn/vO0to3p+3Pi8gKJbmOx0ZD34RLboJpghULsMTk4dXObqS+mbRGQ/8ifFnNfRNgcPjRnpn6GE2/i3u0qKYJRztzglCjO6Pcu8JM6eB0+pCMjytTB8yjQlWOArQ= Received: from MW2PR2101MB1034.namprd21.prod.outlook.com (52.132.149.10) by MW2PR2101MB1065.namprd21.prod.outlook.com (52.132.149.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.2; Sat, 3 Mar 2018 22:33:57 +0000 Received: from MW2PR2101MB1034.namprd21.prod.outlook.com ([fe80::1d56:338f:e2b:cec0]) by MW2PR2101MB1034.namprd21.prod.outlook.com ([fe80::1d56:338f:e2b:cec0%3]) with mapi id 15.20.0567.006; Sat, 3 Mar 2018 22:33:57 +0000 From: Sasha Levin To: "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" CC: Peter Zijlstra , "juri.lelli@arm.com" , "bigeasy@linutronix.de" , "xlpang@redhat.com" , "rostedt@goodmis.org" , "mathieu.desnoyers@efficios.com" , "jdesfossez@efficios.com" , "bristot@redhat.com" , Thomas Gleixner , Sasha Levin Subject: [PATCH AUTOSEL for 4.9 104/219] rtmutex: Fix PI chain order integrity Thread-Topic: [PATCH AUTOSEL for 4.9 104/219] rtmutex: Fix PI chain order integrity Thread-Index: AQHTsz8EdS8EOF0QP0iBWGHu1X/0lA== Date: Sat, 3 Mar 2018 22:28:56 +0000 Message-ID: <20180303222716.26640-104-alexander.levin@microsoft.com> References: <20180303222716.26640-1-alexander.levin@microsoft.com> In-Reply-To: <20180303222716.26640-1-alexander.levin@microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [52.168.54.252] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;MW2PR2101MB1065;7:HFVHH3HMCZfvipO/WbHGI0HYMJogW/n2OIBHQHM6AqD5ZYLHqLtamWOLeqWjdoVlTfygIsDjrRRnn316jOf965w7pflK1+sKZryTGLSMBWhgBVxB/6JWj0B4o3r63NZG3uvbYDXt1DKNVfvbCVM/txbtP+ulDfDN/urue7h84Ltp56PVM2QGrMN27+ALPEK8gVR352k/v0rA8m4TLD//2lPns+f7LGfRzsvVhjo+xOSPr3oqXWqjKgBC7L8yooQU x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 5934ca8d-e018-4d48-2c0a-08d58156dab4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020);SRVR:MW2PR2101MB1065; x-ms-traffictypediagnostic: MW2PR2101MB1065: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Levin@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(89211679590171)(42068640409301); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(8211001083)(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231220)(944501244)(52105095)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011);SRVR:MW2PR2101MB1065;BCL:0;PCL:0;RULEID:;SRVR:MW2PR2101MB1065; x-forefront-prvs: 0600F93FE1 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(366004)(346002)(376002)(396003)(39380400002)(39860400002)(189003)(199004)(6506007)(22452003)(54906003)(25786009)(186003)(2950100002)(102836004)(5250100002)(2501003)(110136005)(97736004)(316002)(2900100001)(36756003)(76176011)(6436002)(59450400001)(6486002)(26005)(4326008)(99286004)(68736007)(6512007)(6116002)(10090500001)(6306002)(106356001)(105586002)(478600001)(66066001)(7416002)(107886003)(3660700001)(966005)(305945005)(86612001)(14454004)(81166006)(7736002)(86362001)(575784001)(1076002)(72206003)(2906002)(10290500003)(8676002)(8936002)(81156014)(3846002)(5660300001)(3280700002)(53936002)(22906009)(217873001);DIR:OUT;SFP:1102;SCL:1;SRVR:MW2PR2101MB1065;H:MW2PR2101MB1034.namprd21.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: XuK2Ph7mMYD1nKadm1XDT0O5ADu87LverTQwPcNqM/v4d4zg609+6+BTZ5RoYjvImfvQAcUo48J+K2MN4/HJ/KcNr9iH3IhRokzTkWue0yDaI8no8Ss/ybt4CtiLTSmZhQtZGA2yVgzK7vnxvGynjmiDMO+IA/8BRGA2NPdpmVI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5934ca8d-e018-4d48-2c0a-08d58156dab4 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2018 22:28:56.1975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1065 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Peter Zijlstra [ Upstream commit e0aad5b44ff5d28ac1d6ae70cdf84ca228e889dc ] rt_mutex_waiter::prio is a copy of task_struct::prio which is updated during the PI chain walk, such that the PI chain order isn't messed up by (asynchronous) task state updates. Currently rt_mutex_waiter_less() uses task state for deadline tasks; this is broken, since the task state can, as said above, change asynchronously, causing the RB tree order to change without actual tree update -> FAIL. Fix this by also copying the deadline into the rt_mutex_waiter state and updating it along with its prio field. Ideally we would also force PI chain updates whenever DL tasks update their deadline parameter, but for first approximation this is less broken than it was. Signed-off-by: Peter Zijlstra (Intel) Cc: juri.lelli@arm.com Cc: bigeasy@linutronix.de Cc: xlpang@redhat.com Cc: rostedt@goodmis.org Cc: mathieu.desnoyers@efficios.com Cc: jdesfossez@efficios.com Cc: bristot@redhat.com Link: http://lkml.kernel.org/r/20170323150216.403992539@infradead.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin --- kernel/locking/rtmutex.c | 29 +++++++++++++++++++++++++++-- kernel/locking/rtmutex_common.h | 1 + 2 files changed, 28 insertions(+), 2 deletions(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 2c49d76f96c3..196cc460e38d 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -236,8 +236,7 @@ rt_mutex_waiter_less(struct rt_mutex_waiter *left, * then right waiter has a dl_prio() too. */ if (dl_prio(left->prio)) - return dl_time_before(left->task->dl.deadline, - right->task->dl.deadline); + return dl_time_before(left->deadline, right->deadline); =20 return 0; } @@ -704,7 +703,26 @@ static int rt_mutex_adjust_prio_chain(struct task_stru= ct *task, =20 /* [7] Requeue the waiter in the lock waiter tree. */ rt_mutex_dequeue(lock, waiter); + + /* + * Update the waiter prio fields now that we're dequeued. + * + * These values can have changed through either: + * + * sys_sched_set_scheduler() / sys_sched_setattr() + * + * or + * + * DL CBS enforcement advancing the effective deadline. + * + * Even though pi_waiters also uses these fields, and that tree is only + * updated in [11], we can do this here, since we hold [L], which + * serializes all pi_waiters access and rb_erase() does not care about + * the values of the node being removed. + */ waiter->prio =3D task->prio; + waiter->deadline =3D task->dl.deadline; + rt_mutex_enqueue(lock, waiter); =20 /* [8] Release the task */ @@ -831,6 +849,8 @@ static int rt_mutex_adjust_prio_chain(struct task_struc= t *task, static int try_to_take_rt_mutex(struct rt_mutex *lock, struct task_struct = *task, struct rt_mutex_waiter *waiter) { + lockdep_assert_held(&lock->wait_lock); + /* * Before testing whether we can acquire @lock, we set the * RT_MUTEX_HAS_WAITERS bit in @lock->owner. This forces all @@ -958,6 +978,8 @@ static int task_blocks_on_rt_mutex(struct rt_mutex *loc= k, struct rt_mutex *next_lock; int chain_walk =3D 0, res; =20 + lockdep_assert_held(&lock->wait_lock); + /* * Early deadlock detection. We really don't want the task to * enqueue on itself just to untangle the mess later. It's not @@ -975,6 +997,7 @@ static int task_blocks_on_rt_mutex(struct rt_mutex *loc= k, waiter->task =3D task; waiter->lock =3D lock; waiter->prio =3D task->prio; + waiter->deadline =3D task->dl.deadline; =20 /* Get the top priority waiter on the lock */ if (rt_mutex_has_waiters(lock)) @@ -1080,6 +1103,8 @@ static void remove_waiter(struct rt_mutex *lock, struct task_struct *owner =3D rt_mutex_owner(lock); struct rt_mutex *next_lock; =20 + lockdep_assert_held(&lock->wait_lock); + raw_spin_lock(¤t->pi_lock); rt_mutex_dequeue(lock, waiter); current->pi_blocked_on =3D NULL; diff --git a/kernel/locking/rtmutex_common.h b/kernel/locking/rtmutex_commo= n.h index e317e1cbb3eb..50848b460851 100644 --- a/kernel/locking/rtmutex_common.h +++ b/kernel/locking/rtmutex_common.h @@ -33,6 +33,7 @@ struct rt_mutex_waiter { struct rt_mutex *deadlock_lock; #endif int prio; + u64 deadline; }; =20 /* --=20 2.14.1