From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 932A0C83F17 for ; Fri, 11 Jul 2025 02:11:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3741B6B00A0; Thu, 10 Jul 2025 22:11:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 34BE46B00A1; Thu, 10 Jul 2025 22:11:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2887F6B00A4; Thu, 10 Jul 2025 22:11:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 18CE46B00A0 for ; Thu, 10 Jul 2025 22:11:12 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A3A631413B1 for ; Fri, 11 Jul 2025 02:11:11 +0000 (UTC) X-FDA: 83650356342.23.2E5A543 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf23.hostedemail.com (Postfix) with ESMTP id 65F5D14000A for ; Fri, 11 Jul 2025 02:11:09 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; spf=pass (imf23.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752199869; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=M4FuFyIhaKWQ9IY1d9E8e2SU3FPYmT8fAOBa1QqKOVE=; b=GEeZb54S2Fzy21N/LkqEFy1rI/niKHaBD0eMSiWxHhmEYUk03mNHqioTRwWuwSRB7p19A7 oWV/J5HACYbcSAmnmwkpve+GPUxu8dtSYEFwggoBDLYFv4vpQB9Bo9BJtjzrr9HcearbQ2 /bGqr2oeLzG48YAvWUavwPStIhvZerU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752199869; a=rsa-sha256; cv=none; b=MwuELFFW0WziwJHjyXSKY+LTiZgUtBAB+KpWtQTxMAzDUD8fDqgljq2RBX+1yVji8AxY2P Slr47ejD4QoO+M/OXR/jpOxFQNpPSx+JfLwmRvPa6xOuqgRn4jw0/iyPb5lgSqurZs9GJp X+UyaSqlU0jzMK6yR2SIDs74TjEU8P8= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com X-AuditID: a67dfc5b-681ff7000002311f-17-687072b9b6c9 Date: Fri, 11 Jul 2025 11:11:00 +0900 From: Byungchul Park To: Andrey Konovalov Cc: Yeoreum Yun , akpm@linux-foundation.org, glider@google.com, dvyukov@google.com, vincenzo.frascino@arm.com, bigeasy@linutronix.de, clrkwllms@kernel.org, rostedt@goodmis.org, max.byungchul.park@gmail.com, ysk@kzalloc.com, kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, kernel_team@skhynix.com Subject: Re: [PATCH v2] kasan: remove kasan_find_vm_area() to prevent possible deadlock Message-ID: <20250711021100.GA4320@system.software.com> References: <20250703181018.580833-1-yeoreum.yun@arm.com> <20250711020858.GA78977@system.software.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250711020858.GA78977@system.software.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsXC9ZZnoe7OooIMg6/fNS3mrF/DZvF94nR2 i2kXJzFbLHvyj8liwsM2dov2j3uZLVY8u89kcXnXHDaLe2v+s1pcWn2BxeLCxF5Wi30dD5gs 9v77yWIx94uhxZfVq9gc+D3WzFvD6LFz1l12j5Z9t9g9Fmwq9dgz8SSbx6ZVnUDi0yR2j4W/ XzB7vDt3jt3jxIzfLB4vNs9k9Pi8SS6AJ4rLJiU1J7MstUjfLoEr4/WUSWwFJ4QrOtYdZG5g 3MfbxcjJISFgInH52RoWGHvz8dvMIDaLgKrE7J/vmEBsNgF1iRs3foLFRQS0JSbc+AVUz8XB LNDGLPFn811WkISwQKRE87ZrYA28AuYSzU9nghUJCaxnlPj16idUQlDi5MwnYNuYgab+mXcJ aCoHkC0tsfwfB0RYXqJ562ywZZwClhKvp2xlB7FFBZQlDmw7zgQyU0JgGbvE8/NLmSGulpQ4 uOIGywRGwVlIVsxCsmIWwopZSFYsYGRZxSiUmVeWm5iZY6KXUZmXWaGXnJ+7iREYoctq/0Tv YPx0IfgQowAHoxIPr8Pq/Awh1sSy4srcQ4wSHMxKIrzrfAsyhHhTEiurUovy44tKc1KLDzFK c7AoifMafStPERJITyxJzU5NLUgtgskycXBKNTBKeBz6yvDh+PZ8DdbUkoN8iw5FzH4Vlc0l MmH219LrNoopYnXpC+6pm1dyr9zLHq7NdvvXhWnSHx9sWr7HY9Lm20uLz++NWDrB47/G+kd3 tmxxPfn01NmFJ126196uC5vzQFa8Sr4jOztZpbnzckZx5or1+q3TK7dOTJx89JmHyrLLlVcz TUPuK7EUZyQaajEXFScCAB4frvrMAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsXC5WfdrLuzqCDDoPuktMWc9WvYLL5PnM5u Me3iJGaLZU/+MVlMeNjGbtH+cS+zxYpn95ksDs89yWpxedccNot7a/6zWlxafYHF4sLEXlaL fR0PmCz2/vvJYjH3i6HFl9Wr2BwEPNbMW8PosXPWXXaPln232D0WbCr12DPxJJvHplWdQOLT JHaPhb9fMHu8O3eO3ePEjN8sHi82z2T0WPziA5PH501yAbxRXDYpqTmZZalF+nYJXBmvp0xi KzghXNGx7iBzA+M+3i5GTg4JAROJzcdvM4PYLAKqErN/vmMCsdkE1CVu3PgJFhcR0JaYcOMX SxcjFwezQBuzxJ/Nd1lBEsICkRLN266BNfAKmEs0P50JViQksJ5R4tern1AJQYmTM5+wgNjM QFP/zLsENJUDyJaWWP6PAyIsL9G8dTbYMk4BS4nXU7ayg9iiAsoSB7YdZ5rAyDcLyaRZSCbN Qpg0C8mkBYwsqxhFMvPKchMzc0z1irMzKvMyK/SS83M3MQLjbVntn4k7GL9cdj/EKMDBqMTD 67A6P0OINbGsuDL3EKMEB7OSCO8634IMId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxe4akJQgLp iSWp2ampBalFMFkmDk6pBsY718TSjfVnFbI07tWb/Jj77yyxzhvpdYqHVRizjy94rv5+l8tJ Ywe9STF39VZLvY8QWVUnaW55LCBWWkY9aYmmgdb0k2F63oz1jNIXefxUWq4tavfuC565/nu+ 9HnvqCkF1iktiwT2+QesrlqjsvbA1Y6WhYt/7KxPO95du4tr87WY2SGy15VYijMSDbWYi4oT AQ9n3/KzAgAA X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Queue-Id: 65F5D14000A X-Rspamd-Server: rspam03 X-Stat-Signature: kabi1bo3khpq1jh4iriy7sdjgxdj16bc X-HE-Tag: 1752199869-617553 X-HE-Meta: U2FsdGVkX19LcBLidEH409UAf4KPkl+Gy5DzBI+8so0r6MHD7bu4m2HSnI/gkL9y+S5qYSnsF+ZMNnrocf8GIbp4d3UohrIBDjmQBLTaScBb4OCycyFbFNRdpaSxPQMn51BCq/cVQPuGs4/q9hgR95T+jV/c4TXOBfvXEf740ZAsdo89MS5qxPRQujVnt0c/ge/DyvkSlA/X4a1c3E/yvr+tSlghczUzL/1rH9CCT6L5bWTDH2SxiTweMixObg9Tam2K3EZ+yVtwwZgFdyolsg7L9RZmQhb2dOnTqTAmnxBTcrHpXiOyS9bz6NHvSCR+/ZIB4FSaUncvABCRIEOCHAq1/bJjVz/WTntPNjmKSrzOm/kBQH8I3EYIsXkvarpn0lraCHHwhrKKhGxIL8PSGqoILghYD/xvjVIX0O1wRMZOxBiDh6e+AUbcMFtDDFTreYDRnwf+yf61jsFwdHPyjARGsumDukhUDTJ4pbgzAmEPIP9cSkJrFJx2JeaMdUbejWWY6xvxqlxPegvnQ2QTRzltxzCGabSVwrOyxT8R08zVCmVJcJVRmYyUTk+yp62Sofci7F5Go5m5FchkZLpElRQ8ECstBzcFozM2t+c3hko7ObZCc491DDd+ylTeb5FwDh7DMIwJzWBZWMO3Ry8lseIU8umeWzHWc64RK/d688Gzp76n/N/v1B+4hMEvBLkfF8FORas5sUabLeLp6O/Jf1iwaRbUTdPN2819j6qqCpipH7O5Yma37LubkqNN7Zu54nuQBbPeb5xscf29c0sZORMPs9ECAxjiyOWsWNbHNPkW2p7bf5ez4OA1HZqwW4lhHAuAdmIrQGrfLaxmtgck2JRwoPIF3KQZoN8rNOFyp2ghMRHcEbVfb6oNRJyME2vFWo5ogVowNDbFKEfmQbRsnLEsEKGxiB5fe5BwDv2O/AZCNhUpnxD8WdXWQJb0DTMISHVCS8gJLg2eBIIccw7 S0bZ85/V UO9hpA5noVSB/rwmPAokGaKDUzlZV7DWVLatjo+bb+m0TEr6wEPHkYaZj81doWNtm+utLtkNC5xqYaT32BQpOeMJUoEw0hQzEBr8gPN8cQj9sH6S0BCGe1hTB2zCJ2z642mt3PJTdZjRHwC2Aq7Vw9izk/8aeEXC0Ft8i+8ZIVFYrwezkuvOcZ+Taiw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jul 11, 2025 at 11:08:58AM +0900, Byungchul Park wrote: > On Thu, Jul 10, 2025 at 02:43:15PM +0200, Andrey Konovalov wrote: > > On Thu, Jul 3, 2025 at 8:10 PM Yeoreum Yun wrote: > > > > > > find_vm_area() couldn't be called in atomic_context. > > > If find_vm_area() is called to reports vm area information, > > > kasan can trigger deadlock like: > > > > > > CPU0 CPU1 > > > vmalloc(); > > > alloc_vmap_area(); > > > spin_lock(&vn->busy.lock) > > > spin_lock_bh(&some_lock); > > > > > > > > > spin_lock(&some_lock); > > > > > > kasan_report(); > > > print_report(); > > > print_address_description(); > > > kasan_find_vm_area(); > > > find_vm_area(); > > > spin_lock(&vn->busy.lock) // deadlock! > > > > > > To prevent possible deadlock while kasan reports, remove kasan_find_vm_area(). > > > > > > Fixes: c056a364e954 ("kasan: print virtual mapping info in reports") > > > Reported-by: Yunseong Kim > > > Signed-off-by: Yeoreum Yun > > > > As a fix: > > > > Acked-by: Andrey Konovalov > > > > But it would be great to figure out a way to eventually restore this > > functionality; I'll file a bug for this once this patch lands. The > > virtual mapping info helps with real issues: e.g. just recently it > > helped me to quickly see the issue that caused a false-positive report > > I checked the critical section by &vn->busy.lock in find_vm_area(). The > time complextity looks O(log N). I don't think an irq disabled section > of O(log N) is harmful. I still think using > spin_lock_irqsave(&vn->busy.lock) can resolve this issue with no worry > of significant irq delay. Am I missing something? I prefer this one tho. Byungchul > > If it's unacceptable for some reasons, why don't we introduce kind of > try_find_vm_area() using trylock so as to go ahead only if there's no > lock contention? > > Byungchul > > > [1]. > > > > [1] https://lore.kernel.org/all/CA+fCnZfzHOFjVo43UZK8H6h3j=OHjfF13oFJvT0P-SM84Oc4qQ@mail.gmail.com/