Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp270713imj; Fri, 15 Feb 2019 23:34:33 -0800 (PST) X-Google-Smtp-Source: AHgI3IaA6oZ8hmeHLE5S3int6tA3BwrRVmstlupdmCSnciQdy4rYmjiTZBsRMZFMPyObYlhvfMiQ X-Received: by 2002:a62:4389:: with SMTP id l9mr14264807pfi.170.1550302473207; Fri, 15 Feb 2019 23:34:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550302473; cv=none; d=google.com; s=arc-20160816; b=EPj3S6IX3m60x+QGmm1jhb7yYxTF8qA4KjrRXxuuEzvOj2QH7o0f5tjK/4JlEdH3xq nbvJ1RGOulxV/PpbpoJDZTvAghTkEI8zsHu3fDyIJjzuiLPrexMk2PEK39N7Bl3nRHwY msbyhRA9Aj84l3XM0OwAkyzZPsQYaGRlmLfyRpce9IrUy+Yb+z4yHHh+wV00TJUKl0bh a0OxQp1SbDa6vNB0VqINunJK5UuADPfTC9+pWkXNk55vYT1T3xa9o+2lBhHFk7vkQQPO Uh7ntpy8sYbINn4XgLILJ1kg7euOW6ZOwHvdGLOaXyHLR/9QZ5YSa+zYr5LxEHbn1jrD AQFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=HXBR8Orio0dcTb81P47d5eEfwU8wnsZ4jYPHCofvhAs=; b=lpGTUi1LLg8dcuodo7RiGwpZEwiiimklXJ/LPTmx2IuWbjzE/TpAzeKcV+33drP+j0 RyVDVGGWwSbo1P9nB4j8/eLMaPzsnsQYvN6J3z5FIkVVkGg5n5DyUux/NoPklo9yBvsE EZHqMrxPlOVnXx/UGVyjAopC8kkOIEDJ1vDGcEjLW7LcSzPYRrWjSQ4K6ppMFHlbVoKo tMhD2hrCY08xXnKB2KSy3vg9YENkSa3RnHCqH17QF49Eeghu287XG/3mHXdFNPUkza5T J5fCxfFaZPxAfj9BZLpMiu78mymQY3DZr58R9L5mx/2tfprFRs5RPSwvVrLgUcyR+oPc 9WQA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h3si7464164pgc.354.2019.02.15.23.34.17; Fri, 15 Feb 2019 23:34:33 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391574AbfBOUuj (ORCPT + 99 others); Fri, 15 Feb 2019 15:50:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54526 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404035AbfBOUub (ORCPT ); Fri, 15 Feb 2019 15:50:31 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 43887ED264; Fri, 15 Feb 2019 20:50:30 +0000 (UTC) Received: from llong.com (dhcp-17-59.bos.redhat.com [10.18.17.59]) by smtp.corp.redhat.com (Postfix) with ESMTP id D9E255BBB4; Fri, 15 Feb 2019 20:50:28 +0000 (UTC) From: Waiman Long To: Peter Zijlstra , Ingo Molnar , Will Deacon , Thomas Gleixner Cc: linux-kernel@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 v2 06/10] locking/rwsem: Enhance DEBUG_RWSEMS_WARN_ON() macro Date: Fri, 15 Feb 2019 15:50:06 -0500 Message-Id: <1550263810-31947-7-git-send-email-longman@redhat.com> In-Reply-To: <1550263810-31947-1-git-send-email-longman@redhat.com> References: <1550263810-31947-1-git-send-email-longman@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 15 Feb 2019 20:50:30 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently, the DEBUG_RWSEMS_WARN_ON() macro just dumps a stack trace when the rwsem isn't in the right state. It does not show the actual states of the rwsem. This may not be that helpful in the debugging process. Enhance the DEBUG_RWSEMS_WARN_ON() macro to also show the current content of the rwsem count and owner fields to give more information about what is wrong with the rwsem. Signed-off-by: Waiman Long --- kernel/locking/rwsem.c | 3 ++- kernel/locking/rwsem.h | 19 ++++++++++++------- 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c index 90de5f1..ccbf18f 100644 --- a/kernel/locking/rwsem.c +++ b/kernel/locking/rwsem.c @@ -198,7 +198,8 @@ int __sched down_write_killable_nested(struct rw_semaphore *sem, int subclass) void up_read_non_owner(struct rw_semaphore *sem) { - DEBUG_RWSEMS_WARN_ON(!((unsigned long)sem->owner & RWSEM_READER_OWNED)); + DEBUG_RWSEMS_WARN_ON(!((unsigned long)sem->owner & RWSEM_READER_OWNED), + sem); __up_read(sem); } diff --git a/kernel/locking/rwsem.h b/kernel/locking/rwsem.h index 1d8f722..c8fd3f1 100644 --- a/kernel/locking/rwsem.h +++ b/kernel/locking/rwsem.h @@ -27,9 +27,13 @@ #define RWSEM_ANONYMOUSLY_OWNED (1UL << 1) #ifdef CONFIG_DEBUG_RWSEMS -# define DEBUG_RWSEMS_WARN_ON(c) DEBUG_LOCKS_WARN_ON(c) +# define DEBUG_RWSEMS_WARN_ON(c, sem) \ + WARN_ONCE(c, "DEBUG_RWSEMS_WARN_ON(%s): count = 0x%lx, owner = 0x%lx, curr 0x%lx, list %sempty\n",\ + #c, atomic_long_read(&(sem)->count), \ + (long)((sem)->owner), (long)current, \ + list_empty(&(sem)->wait_list) ? "" : "not ") #else -# define DEBUG_RWSEMS_WARN_ON(c) +# define DEBUG_RWSEMS_WARN_ON(c, sem) #endif /* @@ -168,7 +172,7 @@ static inline void __down_read(struct rw_semaphore *sem) if (unlikely(atomic_long_inc_return_acquire(&sem->count) <= 0)) { rwsem_down_read_failed(sem); DEBUG_RWSEMS_WARN_ON(!((unsigned long)sem->owner & - RWSEM_READER_OWNED)); + RWSEM_READER_OWNED), sem); } else { rwsem_set_reader_owned(sem); } @@ -180,7 +184,7 @@ static inline int __down_read_killable(struct rw_semaphore *sem) if (IS_ERR(rwsem_down_read_failed_killable(sem))) return -EINTR; DEBUG_RWSEMS_WARN_ON(!((unsigned long)sem->owner & - RWSEM_READER_OWNED)); + RWSEM_READER_OWNED), sem); } else { rwsem_set_reader_owned(sem); } @@ -251,7 +255,8 @@ static inline void __up_read(struct rw_semaphore *sem) { long tmp; - DEBUG_RWSEMS_WARN_ON(!((unsigned long)sem->owner & RWSEM_READER_OWNED)); + DEBUG_RWSEMS_WARN_ON(!((unsigned long)sem->owner & RWSEM_READER_OWNED), + sem); rwsem_clear_reader_owned(sem); tmp = atomic_long_dec_return_release(&sem->count); if (unlikely(tmp < -1 && (tmp & RWSEM_ACTIVE_MASK) == 0)) @@ -263,7 +268,7 @@ static inline void __up_read(struct rw_semaphore *sem) */ static inline void __up_write(struct rw_semaphore *sem) { - DEBUG_RWSEMS_WARN_ON(sem->owner != current); + DEBUG_RWSEMS_WARN_ON(sem->owner != current, sem); rwsem_clear_owner(sem); if (unlikely(atomic_long_sub_return_release(RWSEM_ACTIVE_WRITE_BIAS, &sem->count) < 0)) @@ -284,7 +289,7 @@ static inline void __downgrade_write(struct rw_semaphore *sem) * read-locked region is ok to be re-ordered into the * write side. As such, rely on RELEASE semantics. */ - DEBUG_RWSEMS_WARN_ON(sem->owner != current); + DEBUG_RWSEMS_WARN_ON(sem->owner != current, sem); tmp = atomic_long_add_return_release(-RWSEM_WAITING_BIAS, &sem->count); rwsem_set_reader_owned(sem); if (tmp < 0) -- 1.8.3.1