From patchwork Thu Feb 7 19:07:26 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Waiman Long X-Patchwork-Id: 10801977 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id DB658746 for ; Thu, 7 Feb 2019 19:10:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CBFC22E05F for ; Thu, 7 Feb 2019 19:10:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C01D22E068; Thu, 7 Feb 2019 19:10:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6138F2E05F for ; Thu, 7 Feb 2019 19:10:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727641AbfBGTKa (ORCPT ); Thu, 7 Feb 2019 14:10:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47968 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727594AbfBGTK0 (ORCPT ); Thu, 7 Feb 2019 14:10:26 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 03F0B37E85; Thu, 7 Feb 2019 19:10:26 +0000 (UTC) Received: from llong.com (dhcp-17-35.bos.redhat.com [10.18.17.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id DB62662FA3; Thu, 7 Feb 2019 19:10:23 +0000 (UTC) From: Waiman Long To: Peter Zijlstra , Ingo Molnar , Will Deacon , Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-arch@vger.kernel.org, x86@kernel.org, Arnd Bergmann , Borislav Petkov , "H. Peter Anvin" , Davidlohr Bueso , Linus Torvalds , Andrew Morton , Tim Chen , Waiman Long Subject: [PATCH-tip 22/22] locking/rwsem: Ensure an RT task will not spin on reader Date: Thu, 7 Feb 2019 14:07:26 -0500 Message-Id: <1549566446-27967-23-git-send-email-longman@redhat.com> In-Reply-To: <1549566446-27967-1-git-send-email-longman@redhat.com> References: <1549566446-27967-1-git-send-email-longman@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 07 Feb 2019 19:10:26 +0000 (UTC) Sender: linux-sh-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sh@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP An RT task can do optimistic spinning only if the lock holder is actually running. If the state of the lock holder isn't known, there is a possibility that high priority of the RT task may block forward progress of the lock holder if they happen to reside on the same CPU. This will lead to deadlock. So we have to make sure that an RT task will not spin on a reader-owned rwsem. Signed-off-by: Waiman Long --- kernel/locking/rwsem-xadd.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c index 3cf2e84..ac1f6c4 100644 --- a/kernel/locking/rwsem-xadd.c +++ b/kernel/locking/rwsem-xadd.c @@ -349,12 +349,14 @@ static inline bool rwsem_can_spin_on_owner(struct rw_semaphore *sem) /* * Return the folowing three values depending on the lock owner state. + * 2 when owner is currently NULL * 1 when owner changes and no reader is detected yet. * 0 when owner changes and the new owner may be a reader. * -1 when optimistic spinning has to stop because either the owner stops * running, is unknown, or its timeslice has been used up. */ enum owner_state { + OWNER_NULL = 2, OWNER_SPINNABLE = 1, OWNER_READER = 0, OWNER_NONSPINNABLE = -1, @@ -405,7 +407,8 @@ static noinline enum owner_state rwsem_spin_on_owner(struct rw_semaphore *sem) owner = rwsem_get_owner(sem); if (!is_rwsem_owner_spinnable(owner)) return OWNER_NONSPINNABLE; - return is_rwsem_owner_reader(owner) ? OWNER_READER : OWNER_SPINNABLE; + return !owner ? OWNER_NULL : + is_rwsem_owner_reader(owner) ? OWNER_READER : OWNER_SPINNABLE; } static bool rwsem_optimistic_spin(struct rw_semaphore *sem, const long wlock) @@ -442,12 +445,13 @@ static bool rwsem_optimistic_spin(struct rw_semaphore *sem, const long wlock) break; /* - * When there's no owner, we might have preempted between the - * owner acquiring the lock and setting the owner field. If - * we're an RT task that will live-lock because we won't let - * the owner complete. + * An RT task cannot do optimistic spinning if it cannot + * be sure the lock holder is running. When there's no owner + * or is reader-owned, an RT task has to stop spinning or + * live-lock may happen if the current task and the lock + * holder happen to run in the same CPU. */ - if (!rwsem_get_owner(sem) && + if ((owner_state != OWNER_SPINNABLE) && (need_resched() || rt_task(current))) break;