From nobody Thu Dec 18 20:17:36 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30FC224BBF7 for ; Thu, 13 Feb 2025 20:02:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739476970; cv=none; b=IFtUjRhRj2Nmmz91ULMCYYsMTd+l15uLSTDymkCVcokA5h3yAPtwBTeJ72wnV9K4ht6/W9MLNpb8yg1N45kYImK0frysA4PCRzD2Qa6/ePLcbnr3PI1XNvyLA8m3qYXxvqh9mI0hYZPyRBSLt1ru+m1ylZEQpJY+vQ8juIAEFLU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739476970; c=relaxed/simple; bh=xQnYCBQJlOCqN0QxyY/yXcLZ+NgzI2pqR3+zsf/WQWI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y0noV+DLWbj4E3h/FrAe77krRLgzMKMCminuq3nb8lVqshG6LoVVG3Y+q4hln8NIHA+Nr4mn2cUIvPyxtfNNy2O4C2xYc8SgrJNIBtJBWVbMteJGcBFVmB6UfEk6/ikq0RjQpWiYon+ek4WdsilgWzyc7re2HV8y9bEdCDUV3p8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=M/jFSOpf; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="M/jFSOpf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739476968; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/2qiXC/cNFFNJmD/Jr1WU9cXX6QUwEFoWyQGXl5gh0Q=; b=M/jFSOpf95M2QZ+T/sUZHdpXv6f094OESBjln220MD1eytLhzjRW7wOg27NyAZ1eOqazdx Yo40Mu4Op1+TKIIGhBiH0dyCAYdlxurMPh9waK70+UkrESs7CtBz2LMcrh+e1mNMpi8blJ QuD/14V4XsDKre3+/UcrINimFyBFlRE= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-543-_VGgiUUcOfCNkxtkAmgh3Q-1; Thu, 13 Feb 2025 15:02:43 -0500 X-MC-Unique: _VGgiUUcOfCNkxtkAmgh3Q-1 X-Mimecast-MFC-AGG-ID: _VGgiUUcOfCNkxtkAmgh3Q Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 02D4E19560B5; Thu, 13 Feb 2025 20:02:42 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.88.174]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 53E5A180035E; Thu, 13 Feb 2025 20:02:39 +0000 (UTC) From: Waiman Long To: Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Marco Elver Cc: linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Waiman Long Subject: [PATCH v4 1/4] locking/lock_events: Add locking events for rtmutex slow paths Date: Thu, 13 Feb 2025 15:02:25 -0500 Message-ID: <20250213200228.1993588-2-longman@redhat.com> In-Reply-To: <20250213200228.1993588-1-longman@redhat.com> References: <20250213200228.1993588-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" Add locking events for rtlock_slowlock() and rt_mutex_slowlock() for profiling the slow path behavior of rt_spin_lock() and rt_mutex_lock(). Signed-off-by: Waiman Long --- kernel/locking/lock_events_list.h | 21 +++++++++++++++++++++ kernel/locking/rtmutex.c | 29 ++++++++++++++++++++++++----- 2 files changed, 45 insertions(+), 5 deletions(-) diff --git a/kernel/locking/lock_events_list.h b/kernel/locking/lock_events= _list.h index 97fb6f3f840a..80b11f194c9f 100644 --- a/kernel/locking/lock_events_list.h +++ b/kernel/locking/lock_events_list.h @@ -67,3 +67,24 @@ LOCK_EVENT(rwsem_rlock_handoff) /* # of read lock handof= fs */ LOCK_EVENT(rwsem_wlock) /* # of write locks acquired */ LOCK_EVENT(rwsem_wlock_fail) /* # of failed write lock acquisitions */ LOCK_EVENT(rwsem_wlock_handoff) /* # of write lock handoffs */ + +/* + * Locking events for rtlock_slowlock() + */ +LOCK_EVENT(rtlock_slowlock) /* # of rtlock_slowlock() calls */ +LOCK_EVENT(rtlock_slow_acq1) /* # of locks acquired after wait_lock */ +LOCK_EVENT(rtlock_slow_acq2) /* # of locks acquired in for loop */ +LOCK_EVENT(rtlock_slow_sleep) /* # of sleeps */ +LOCK_EVENT(rtlock_slow_wake) /* # of wakeup's */ + +/* + * Locking events for rt_mutex_slowlock() + */ +LOCK_EVENT(rtmutex_slowlock) /* # of rt_mutex_slowlock() calls */ +LOCK_EVENT(rtmutex_slow_block) /* # of rt_mutex_slowlock_block() calls */ +LOCK_EVENT(rtmutex_slow_acq1) /* # of locks acquired after wait_lock */ +LOCK_EVENT(rtmutex_slow_acq2) /* # of locks acquired at the end */ +LOCK_EVENT(rtmutex_slow_acq3) /* # of locks acquired in *block() */ +LOCK_EVENT(rtmutex_slow_sleep) /* # of sleeps */ +LOCK_EVENT(rtmutex_slow_wake) /* # of wakeup's */ +LOCK_EVENT(rtmutex_deadlock) /* # of rt_mutex_handle_deadlock()'s */ diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 4a8df1800cbb..c80902eacd79 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -27,6 +27,7 @@ #include =20 #include "rtmutex_common.h" +#include "lock_events.h" =20 #ifndef WW_RT # define build_ww_mutex() (false) @@ -1612,10 +1613,13 @@ static int __sched rt_mutex_slowlock_block(struct r= t_mutex_base *lock, struct task_struct *owner; int ret =3D 0; =20 + lockevent_inc(rtmutex_slow_block); for (;;) { /* Try to acquire the lock: */ - if (try_to_take_rt_mutex(lock, current, waiter)) + if (try_to_take_rt_mutex(lock, current, waiter)) { + lockevent_inc(rtmutex_slow_acq3); break; + } =20 if (timeout && !timeout->task) { ret =3D -ETIMEDOUT; @@ -1638,8 +1642,10 @@ static int __sched rt_mutex_slowlock_block(struct rt= _mutex_base *lock, owner =3D NULL; raw_spin_unlock_irq_wake(&lock->wait_lock, wake_q); =20 - if (!owner || !rtmutex_spin_on_owner(lock, waiter, owner)) + if (!owner || !rtmutex_spin_on_owner(lock, waiter, owner)) { + lockevent_inc(rtmutex_slow_sleep); rt_mutex_schedule(); + } =20 raw_spin_lock_irq(&lock->wait_lock); set_current_state(state); @@ -1694,6 +1700,7 @@ static int __sched __rt_mutex_slowlock(struct rt_mute= x_base *lock, int ret; =20 lockdep_assert_held(&lock->wait_lock); + lockevent_inc(rtmutex_slowlock); =20 /* Try to acquire the lock again: */ if (try_to_take_rt_mutex(lock, current, NULL)) { @@ -1701,6 +1708,7 @@ static int __sched __rt_mutex_slowlock(struct rt_mute= x_base *lock, __ww_mutex_check_waiters(rtm, ww_ctx, wake_q); ww_mutex_lock_acquired(ww, ww_ctx); } + lockevent_inc(rtmutex_slow_acq1); return 0; } =20 @@ -1719,10 +1727,12 @@ static int __sched __rt_mutex_slowlock(struct rt_mu= tex_base *lock, __ww_mutex_check_waiters(rtm, ww_ctx, wake_q); ww_mutex_lock_acquired(ww, ww_ctx); } + lockevent_inc(rtmutex_slow_acq2); } else { __set_current_state(TASK_RUNNING); remove_waiter(lock, waiter); rt_mutex_handle_deadlock(ret, chwalk, lock, waiter); + lockevent_inc(rtmutex_deadlock); } =20 /* @@ -1751,6 +1761,7 @@ static inline int __rt_mutex_slowlock_locked(struct r= t_mutex_base *lock, &waiter, wake_q); =20 debug_rt_mutex_free_waiter(&waiter); + lockevent_cond_inc(rtmutex_slow_wake, !wake_q_empty(wake_q)); return ret; } =20 @@ -1823,9 +1834,12 @@ static void __sched rtlock_slowlock_locked(struct rt= _mutex_base *lock, struct task_struct *owner; =20 lockdep_assert_held(&lock->wait_lock); + lockevent_inc(rtlock_slowlock); =20 - if (try_to_take_rt_mutex(lock, current, NULL)) + if (try_to_take_rt_mutex(lock, current, NULL)) { + lockevent_inc(rtlock_slow_acq1); return; + } =20 rt_mutex_init_rtlock_waiter(&waiter); =20 @@ -1838,8 +1852,10 @@ static void __sched rtlock_slowlock_locked(struct rt= _mutex_base *lock, =20 for (;;) { /* Try to acquire the lock again */ - if (try_to_take_rt_mutex(lock, current, &waiter)) + if (try_to_take_rt_mutex(lock, current, &waiter)) { + lockevent_inc(rtlock_slow_acq2); break; + } =20 if (&waiter =3D=3D rt_mutex_top_waiter(lock)) owner =3D rt_mutex_owner(lock); @@ -1847,8 +1863,10 @@ static void __sched rtlock_slowlock_locked(struct rt= _mutex_base *lock, owner =3D NULL; raw_spin_unlock_irq_wake(&lock->wait_lock, wake_q); =20 - if (!owner || !rtmutex_spin_on_owner(lock, &waiter, owner)) + if (!owner || !rtmutex_spin_on_owner(lock, &waiter, owner)) { + lockevent_inc(rtlock_slow_sleep); schedule_rtlock(); + } =20 raw_spin_lock_irq(&lock->wait_lock); set_current_state(TASK_RTLOCK_WAIT); @@ -1865,6 +1883,7 @@ static void __sched rtlock_slowlock_locked(struct rt_= mutex_base *lock, debug_rt_mutex_free_waiter(&waiter); =20 trace_contention_end(lock, 0); + lockevent_cond_inc(rtlock_slow_wake, !wake_q_empty(wake_q)); } =20 static __always_inline void __sched rtlock_slowlock(struct rt_mutex_base *= lock) --=20 2.48.1 From nobody Thu Dec 18 20:17:36 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 002622661A7 for ; Thu, 13 Feb 2025 20:02:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739476974; cv=none; b=mcnxzaEyRP6vUs4dlDzfyREPRe98hq0hZDBpKxh/elTgZwCtP4R2oZ1kuq/t/hicF64AUFiegbzHFF9rcdgBI6O9zQRhrbQJ9vHMUJ9awZTLFNvYVSdAnxx2LgBVDifvKpCqvW7urOlLVG0z/YSwX5OkhVObvxQnIFP5gHLblOw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739476974; c=relaxed/simple; bh=EUVQgYDdQvDpbP5AdqIWHackolUC0UTmiQ6+5AfhcxM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MqsccsqaXN/EywI2/GKs/wssPkAfjNE060uUHqARM2Adx/SUhVSR0Ih6wVT2iwuhkB1FNBWpK5oDk70duBYhqL6Epm1QleHXVxHVCnNl+70nqDQAT2a/gPkiBmbc8rkyXXquP/M1ezZKqjZ1rO7GxHQ2yi++5AyiFcrgyOGa4dI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ebsMz1H/; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ebsMz1H/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739476971; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jCz7+XdNeTmg0ywryfA79K8sDfbhrWMKHNAgiZbFNpE=; b=ebsMz1H/aCFoVz1mpPLHDVg82TpSr0VRnPdp+ML/ZpgeD/OaWYKQtatdQbL1ibEIkSjhvs 7LBEP7hY7+8JMt+lHjWBoek+xHjQ3C4asiUbOQjei4YIPygk9Qc5B4gbK0QU9i93QmTHyX uXhUa6gXd3KL/wyll9bNq08U4CUHUKo= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-433-SsxhO4IwMmWfG-T4-krdSQ-1; Thu, 13 Feb 2025 15:02:47 -0500 X-MC-Unique: SsxhO4IwMmWfG-T4-krdSQ-1 X-Mimecast-MFC-AGG-ID: SsxhO4IwMmWfG-T4-krdSQ Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id AB17619560BC; Thu, 13 Feb 2025 20:02:45 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.88.174]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 70E361800872; Thu, 13 Feb 2025 20:02:42 +0000 (UTC) From: Waiman Long To: Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Marco Elver Cc: linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Waiman Long Subject: [PATCH v4 2/4] locking/lock_events: Add locking events for lockdep Date: Thu, 13 Feb 2025 15:02:26 -0500 Message-ID: <20250213200228.1993588-3-longman@redhat.com> In-Reply-To: <20250213200228.1993588-1-longman@redhat.com> References: <20250213200228.1993588-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" Add some lock events to the lockdep for profiling its behavior. Signed-off-by: Waiman Long --- kernel/locking/lock_events_list.h | 7 +++++++ kernel/locking/lockdep.c | 8 +++++++- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/kernel/locking/lock_events_list.h b/kernel/locking/lock_events= _list.h index 80b11f194c9f..9ef9850aeebe 100644 --- a/kernel/locking/lock_events_list.h +++ b/kernel/locking/lock_events_list.h @@ -88,3 +88,10 @@ LOCK_EVENT(rtmutex_slow_acq3) /* # of locks acquired in = *block() */ LOCK_EVENT(rtmutex_slow_sleep) /* # of sleeps */ LOCK_EVENT(rtmutex_slow_wake) /* # of wakeup's */ LOCK_EVENT(rtmutex_deadlock) /* # of rt_mutex_handle_deadlock()'s */ + +/* + * Locking events for lockdep + */ +LOCK_EVENT(lockdep_acquire) +LOCK_EVENT(lockdep_lock) +LOCK_EVENT(lockdep_nocheck) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 4470680f0226..8436f017c74d 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -61,6 +61,7 @@ #include =20 #include "lockdep_internals.h" +#include "lock_events.h" =20 #include =20 @@ -170,6 +171,7 @@ static struct task_struct *lockdep_selftest_task_struct; static int graph_lock(void) { lockdep_lock(); + lockevent_inc(lockdep_lock); /* * Make sure that if another CPU detected a bug while * walking the graph we dont change it (while the other @@ -5091,8 +5093,12 @@ static int __lock_acquire(struct lockdep_map *lock, = unsigned int subclass, if (unlikely(lock->key =3D=3D &__lockdep_no_track__)) return 0; =20 - if (!prove_locking || lock->key =3D=3D &__lockdep_no_validate__) + lockevent_inc(lockdep_acquire); + + if (!prove_locking || lock->key =3D=3D &__lockdep_no_validate__) { check =3D 0; + lockevent_inc(lockdep_nocheck); + } =20 if (subclass < NR_LOCKDEP_CACHING_CLASSES) class =3D lock->class_cache[subclass]; --=20 2.48.1 From nobody Thu Dec 18 20:17:36 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E83442661B1 for ; Thu, 13 Feb 2025 20:02:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739476976; cv=none; b=QzUabh1ljb4EJFptcKe3i0Klm4E0V76GPaO9LHF3p5D07Xp8lI/kpEWAK+iei5yvsIwFtgWVnpMHWcQwKlKg4KiTG/w6CpjcY5hrVW+zh5FXPrl214v93L0/kOGxDe9eUOIgC2dpxZ0+7KplTKe1bvyN89FApU19bnQwo0UMtcE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739476976; c=relaxed/simple; bh=5+sV00c/Wm6fs0te4L4OWioK04YWyzdbWrzVVZVv2Lg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YBG4uNJr/+lfAZ4sINN9tov6i4kXK58ShNeZvBuqyQiS2uI0W/5XtSsnNgL6VFrPgoB0uqwKNSlXiVwBBhP1NHUJO4eRl/X2VPbjB6G7plisO74MescbA44nbnjF+XkvU46lO3zG1qewXjPLMINXVtTPjEc5qd5HdbAG2aZW8TY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Ar/EPyQS; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Ar/EPyQS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739476974; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oz+7MpT+Dx78HRfBDvJLdqx8byUVr6Veo3C9NU8MZLY=; b=Ar/EPyQSux5vkM+JT6zuOZiYNSQaNNAefNpsGOB2YizjDsqwMSVSeEFilYpRgLmlGTpXAQ 2Nx2LMb0Pt53WPhDM3Moky8A2nrKW5MS8esWO1BnddiaMVc0HcpdsP2VD6jlxZBZYpzUZu 5a4i0PzyL8IpMAiCUL0UxohgsWw5NqQ= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-609--0t1wsnLOGKBHz3JatwlMA-1; Thu, 13 Feb 2025 15:02:50 -0500 X-MC-Unique: -0t1wsnLOGKBHz3JatwlMA-1 X-Mimecast-MFC-AGG-ID: -0t1wsnLOGKBHz3JatwlMA Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6AB25180087D; Thu, 13 Feb 2025 20:02:48 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.88.174]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 00E791800358; Thu, 13 Feb 2025 20:02:45 +0000 (UTC) From: Waiman Long To: Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Marco Elver Cc: linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Waiman Long Subject: [PATCH v4 3/4] locking/lockdep: Disable KASAN instrumentation of lockdep.c Date: Thu, 13 Feb 2025 15:02:27 -0500 Message-ID: <20250213200228.1993588-4-longman@redhat.com> In-Reply-To: <20250213200228.1993588-1-longman@redhat.com> References: <20250213200228.1993588-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" Both KASAN and LOCKDEP are commonly enabled in building a debug kernel. Each of them can significantly slow down the speed of a debug kernel. Enabling KASAN instrumentation of the LOCKDEP code will further slow thing down. Since LOCKDEP is a high overhead debugging tool, it will never get enabled in a production kernel. The LOCKDEP code is also pretty mature and is unlikely to get major changes. There is also a possibility of recursion similar to KCSAN. To evaluate the performance impact of disabling KASAN instrumentation of lockdep.c, the time to do a parallel build of the Linux defconfig kernel was used as the benchmark. Two x86-64 systems (Skylake & Zen 2) and an arm64 system were used as test beds. Two sets of non-RT and RT kernels with similar configurations except mainly CONFIG_PREEMPT_RT were used for evaulation. For the Skylake system: Kernel Run time Sys time ------ -------- -------- Non-debug kernel (baseline) 0m47.642s 4m19.811s [CONFIG_KASAN_INLINE=3Dy] Debug kernel 2m11.108s (x2.8) 38m20.467s (x8.9) Debug kernel (patched) 1m49.602s (x2.3) 31m28.501s (x7.3) Debug kernel (patched + mitigations=3Doff) 1m30.988s (x1.9) 26m41.993s (x6.2) RT kernel (baseline) 0m54.871s 7m15.340s [CONFIG_KASAN_INLINE=3Dn] RT debug kernel 6m07.151s (x6.7) 135m47.428s (x18.7) RT debug kernel (patched) 3m42.434s (x4.1) 74m51.636s (x10.3) RT debug kernel (patched + mitigations=3Doff) 2m40.383s (x2.9) 57m54.369s (x8.0) [CONFIG_KASAN_INLINE=3Dy] RT debug kernel 3m22.155s (x3.7) 77m53.018s (x10.7) RT debug kernel (patched) 2m36.700s (x2.9) 54m31.195s (x7.5) RT debug kernel (patched + mitigations=3Doff) 2m06.110s (x2.3) 45m49.493s (x6.3) For the Zen 2 system: Kernel Run time Sys time ------ -------- -------- Non-debug kernel (baseline) 1m42.806s 39m48.714s [CONFIG_KASAN_INLINE=3Dy] Debug kernel 4m04.524s (x2.4) 125m35.904s (x3.2) Debug kernel (patched) 3m56.241s (x2.3) 127m22.378s (x3.2) Debug kernel (patched + mitigations=3Doff) 2m38.157s (x1.5) 92m35.680s (x2.3) RT kernel (baseline) 1m51.500s 14m56.322s [CONFIG_KASAN_INLINE=3Dn] RT debug kernel 16m04.962s (x8.7) 244m36.463s (x16.4) RT debug kernel (patched) 9m09.073s (x4.9) 129m28.439s (x8.7) RT debug kernel (patched + mitigations=3Doff) 3m31.662s (x1.9) 51m01.391s (x3.4) For the arm64 system: Kernel Run time Sys time ------ -------- -------- Non-debug kernel (baseline) 1m56.844s 8m47.150s Debug kernel 3m54.774s (x2.0) 92m30.098s (x10.5) Debug kernel (patched) 3m32.429s (x1.8) 77m40.779s (x8.8) RT kernel (baseline) 4m01.641s 18m16.777s [CONFIG_KASAN_INLINE=3Dn] RT debug kernel 19m32.977s (x4.9) 304m23.965s (x16.7) RT debug kernel (patched) 16m28.354s (x4.1) 234m18.149s (x12.8) Turning the mitigations off doesn't seems to have any noticeable impact on the performance of the arm64 system. So the mitigation=3Doff entries aren't included. For the x86 CPUs, cpu mitigations has a much bigger impact on performance, especially the RT debug kernel with CONFIG_KASAN_INLINE=3Dn. The SRSO mitigation in Zen 2 has an especially big impact on the debug kernel. It is also the majority of the slowdown with mitigations on. It is because the patched ret instruction slows down function returns. A lot of helper functions that are normally compiled out or inlined may become real function calls in the debug kernel. With CONFIG_KASAN_INLINE=3Dn, the KASAN instrumentation inserts a lot of __asan_loadX*() and __kasan_check_read() function calls to memory access portion of the code. The lockdep's __lock_acquire() function, for instance, has 66 __asan_loadX*() and 6 __kasan_check_read() calls added with KASAN instrumentation. Of course, the actual numbers may vary depending on the compiler used and the exact version of the lockdep code. With the Skylake test system, the parallel kernel build times reduction of the RT debug kernel with this patch are: CONFIG_KASAN_INLINE=3Dn: -37% CONFIG_KASAN_INLINE=3Dy: -22% The time reduction is less with CONFIG_KASAN_INLINE=3Dy, but it is still significant. Setting CONFIG_KASAN_INLINE=3Dy can result in a significant performance improvement. The major drawback is a significant increase in the size of kernel text. In the case of vmlinux, its text size increases from 45997948 to 67606807. That is a 47% size increase (about 21 Mbytes). The size increase of other kernel modules should be similar. With the newly added rtmutex and lockdep lock events, the relevant event counts for the test runs with the Skylake system were: Event type Debug kernel RT debug kernel ---------- ------------ --------------- lockdep_acquire 1,968,663,277 5,425,313,953 rtlock_slowlock - 401,701,156 rtmutex_slowlock - 139,672 The __lock_acquire() calls in the RT debug kernel are x2.8 times of the non-RT debug kernel with the same workload. Since the __lock_acquire() function is a big hitter in term of performance slowdown, this makes the RT debug kernel much slower than the non-RT one. The average lock nesting depth is likely to be higher in the RT debug kernel too leading to longer execution time in the __lock_acquire() function. As the small advantage of enabling KASAN instrumentation to catch potential memory access error in the lockdep debugging tool is probably not worth the drawback of further slowing down a debug kernel, disable KASAN instrumentation in the lockdep code to allow the debug kernels to regain some performance back, especially for the RT debug kernels. Signed-off-by: Waiman Long Reviewed-by: Andrey Konovalov Reviewed-by: Marco Elver --- kernel/locking/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile index 0db4093d17b8..a114949eeed5 100644 --- a/kernel/locking/Makefile +++ b/kernel/locking/Makefile @@ -5,7 +5,8 @@ KCOV_INSTRUMENT :=3D n =20 obj-y +=3D mutex.o semaphore.o rwsem.o percpu-rwsem.o =20 -# Avoid recursion lockdep -> sanitizer -> ... -> lockdep. +# Avoid recursion lockdep -> sanitizer -> ... -> lockdep & improve perform= ance. +KASAN_SANITIZE_lockdep.o :=3D n KCSAN_SANITIZE_lockdep.o :=3D n =20 ifdef CONFIG_FUNCTION_TRACER --=20 2.48.1 From nobody Thu Dec 18 20:17:36 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C56281C8616 for ; Fri, 14 Feb 2025 19:53:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739562793; cv=none; b=AdwfqVLQT9KH+tC7vcHklLcvCqhwa16v1MZhsAdIAsL3NRYrAWA2Rf3BC/T79D77AYiIgRfwU9NqNGPDLsvGNvpWe7GhtufED3/NPuGpPO64kdxiuvjfqvh5TEuMELOKaTy6OM44hlhToUHMRNwQHRE5rUGqURECOV3q2YHWM7Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739562793; c=relaxed/simple; bh=bpqpbEg8UyVMcher6IVTMqGb7iTCJrB20DmRE7Iw29o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QvJOZGUtLHlneh4i3oGa2axHr0NzNuKgsMVBidmiWNktSTev2pnBfrz1NqU0fdjzvgbIkZzsszMk1bqdJ4PsMAXlcr7/o4sDn4U/sI2Z297trxtASys2Myyc6DQkPyBwlwoqwV+STMFO3QXZrqsxJTEdWNi5lK/e/ojIJQUP87g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=UbMi2ujT; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UbMi2ujT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739562790; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v0A/F0sxY6CPbFBG1cOgr1XQMfWgjq/GMhonm5xEbAY=; b=UbMi2ujTzzumnUJ0qeRsxuCbcQbGLsWxsMpQvxxFW3e7zwSAZppxZjZn/Xj8rKGwI77cof gggIS0O/A4wumcKoDpP8HgI+pMo4NNvACTHRd5h9BmrBw1j2ApDwlCyY89mJRzjcywOv5T +Rf4hRcY19/WgWJMeF6wSp0kwgn97K8= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-138-hiKAVQYcPD6OURKxGKIcvA-1; Fri, 14 Feb 2025 14:53:09 -0500 X-MC-Unique: hiKAVQYcPD6OURKxGKIcvA-1 X-Mimecast-MFC-AGG-ID: hiKAVQYcPD6OURKxGKIcvA_1739562787 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 072CE18D95DC; Fri, 14 Feb 2025 19:53:07 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.89.30]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4749C1800874; Fri, 14 Feb 2025 19:53:03 +0000 (UTC) From: Waiman Long To: Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Marco Elver Cc: linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Waiman Long Subject: [PATCH v4.1 4/4] locking/lockdep: Add kasan_check_byte() check in lock_acquire() Date: Fri, 14 Feb 2025 14:52:42 -0500 Message-ID: <20250214195242.2480920-1-longman@redhat.com> In-Reply-To: <20250213200228.1993588-1-longman@redhat.com> References: <20250213200228.1993588-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 Content-Type: text/plain; charset="utf-8" KASAN instrumentation of lockdep has been disabled as we don't need KASAN to check the validity of lockdep internal data structures and incur unnecessary performance overhead. However, the lockdep_map pointer passed in externally may not be valid (e.g. use-after-free) and we run the risk of using garbage data resulting in false lockdep reports. Add kasan_check_byte() call in lock_acquire() for non kernel core data object to catch invalid lockdep_map and print out a KASAN report before any lockdep splat, if any. Suggested-by: Marco Elver Signed-off-by: Waiman Long Reviewed-by: Andrey Konovalov Reviewed-by: Marco Elver --- kernel/locking/lockdep.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 8436f017c74d..b15757e63626 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -57,6 +57,7 @@ #include #include #include +#include =20 #include =20 @@ -5830,6 +5831,14 @@ void lock_acquire(struct lockdep_map *lock, unsigned= int subclass, if (!debug_locks) return; =20 + /* + * As KASAN instrumentation is disabled and lock_acquire() is usually + * the first lockdep call when a task tries to acquire a lock, add + * kasan_check_byte() here to check for use-after-free and other + * memory errors. + */ + kasan_check_byte(lock); + if (unlikely(!lockdep_enabled())) { /* XXX allow trylock from NMI ?!? */ if (lockdep_nmi() && !trylock) { --=20 2.48.1 From nobody Thu Dec 18 20:17:36 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9CDEE2661A7 for ; Thu, 13 Feb 2025 20:02:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739476979; cv=none; b=RWFzLZ1sRI0dXv3sMPzb+3fJ+rZ61NXRSC8rrGO/KAim8ogDStDV/Dot2T5eEfH3EaD66Zn/Jzjxv+1OIp0VAENM0GVLy7Ho/c+/vHNJm6Ty5iy+dmuVkcdDbQnWbwIBkFmRLYKtwuNxuoFj7gVED67u4D8iaocaZCzjxOxrYD0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739476979; c=relaxed/simple; bh=nXCD/LXulwuMSZFXcozil2n1aFaawh8DejNvW9hLXYo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ku8Jk/7VoBV5JcaJqmEWZvVWrmJKWwL7BNVOy4OFyGpiEqnpAPqFuyO/3M67MiJMBbtjbUvoke1Q3d5RXBGJvwxqv8tVc4ofzk6p3HaXkTpLvzi83UgBs2b7z0BlQkl66sl4ZzpFmZ04eAhW4CcUvmZh0uq5+vhQc1x8WRKo9Ls= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=RltJGkhT; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="RltJGkhT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739476976; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oSXvIJINQIfUxBjAhkboBcPP4OyeZ0/nogoPQVNBBqQ=; b=RltJGkhTpd6vOP9JUIdzT90QbVHB8/HxRpBI8ib6aiSKUQ5SM6FXba3w1H15z0tOXti1mk z2vniJ5w1+8JqNGx+fUsa12ZT/BAVrLBpWy+BNZy9VisCUDJJl3kYb6jH62P1w/Yk7HS7Q S8YOho00juYK0qXOo7UbuGjoKAKGQaw= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-678-FV_rQcKIPGaILACE79EL4g-1; Thu, 13 Feb 2025 15:02:53 -0500 X-MC-Unique: FV_rQcKIPGaILACE79EL4g-1 X-Mimecast-MFC-AGG-ID: FV_rQcKIPGaILACE79EL4g Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 14C1B180087F; Thu, 13 Feb 2025 20:02:51 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.88.174]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B57FC1800358; Thu, 13 Feb 2025 20:02:48 +0000 (UTC) From: Waiman Long To: Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Marco Elver Cc: linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Waiman Long Subject: [PATCH v4 4/4] locking/lockdep: Add kasan_check_byte() check in lock_acquire() Date: Thu, 13 Feb 2025 15:02:28 -0500 Message-ID: <20250213200228.1993588-5-longman@redhat.com> In-Reply-To: <20250213200228.1993588-1-longman@redhat.com> References: <20250213200228.1993588-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" KASAN instrumentation of lockdep has been disabled as we don't need KASAN to check the validity of lockdep internal data structures and incur unnecessary performance overhead. However, the lockdep_map pointer passed in externally may not be valid (e.g. use-after-free) and we run the risk of using garbage data resulting in false lockdep reports. Add kasan_check_byte() call in lock_acquire() for non kernel core data object to catch invalid lockdep_map and abort lockdep processing if input data isn't valid. Suggested-by: Marco Elver Signed-off-by: Waiman Long Reviewed-by: Marco Elver --- kernel/locking/lock_events_list.h | 1 + kernel/locking/lockdep.c | 14 ++++++++++++++ 2 files changed, 15 insertions(+) diff --git a/kernel/locking/lock_events_list.h b/kernel/locking/lock_events= _list.h index 9ef9850aeebe..bed59b2195c7 100644 --- a/kernel/locking/lock_events_list.h +++ b/kernel/locking/lock_events_list.h @@ -95,3 +95,4 @@ LOCK_EVENT(rtmutex_deadlock) /* # of rt_mutex_handle_dead= lock()'s */ LOCK_EVENT(lockdep_acquire) LOCK_EVENT(lockdep_lock) LOCK_EVENT(lockdep_nocheck) +LOCK_EVENT(lockdep_kasan_fail) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 8436f017c74d..98dd0455d4be 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -57,6 +57,7 @@ #include #include #include +#include =20 #include =20 @@ -5830,6 +5831,19 @@ void lock_acquire(struct lockdep_map *lock, unsigned= int subclass, if (!debug_locks) return; =20 + /* + * As KASAN instrumentation is disabled and lock_acquire() is usually + * the first lockdep call when a task tries to acquire a lock, add + * kasan_check_byte() here to check for use-after-free of non kernel + * core lockdep_map data to avoid referencing garbage data. + */ + if (unlikely(IS_ENABLED(CONFIG_KASAN) && + !is_kernel_core_data((unsigned long)lock) && + !kasan_check_byte(lock))) { + lockevent_inc(lockdep_kasan_fail); + return; + } + if (unlikely(!lockdep_enabled())) { /* XXX allow trylock from NMI ?!? */ if (lockdep_nmi() && !trylock) { --=20 2.48.1