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 303EDC021A9 for ; Mon, 17 Feb 2025 17:56:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F44C28007C; Mon, 17 Feb 2025 12:56:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A3D228007B; Mon, 17 Feb 2025 12:56:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 444EC28007C; Mon, 17 Feb 2025 12:56:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 173D428007B for ; Mon, 17 Feb 2025 12:56:34 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0F2D4160B0D for ; Mon, 17 Feb 2025 17:56:33 +0000 (UTC) X-FDA: 83130191466.22.A2B9585 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf17.hostedemail.com (Postfix) with ESMTP id 8803A40012 for ; Mon, 17 Feb 2025 17:56:30 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Mdeo+KhA; spf=pass (imf17.hostedemail.com: domain of llong@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=llong@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739814990; 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:dkim-signature; bh=niJ7GrqnlE8mjwkLXdroJsmq3cDp8d9woXPb/vSi3Z0=; b=eUKdSUlcViV0ZYXvKcgDg9Gla7c7vpEmB3lcV2VUjmY0hn3I4qndLJ40zxA/uherpsbsVK EJm/urK7GzshXXJ4hK3o/K17JodCHcUXjvccmwuKbSAEukbRq+P3UPcoA2o+LgbIbCTyrD AM/wVmfmW5ky3M/D0MQr5E7GMw09c+o= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Mdeo+KhA; spf=pass (imf17.hostedemail.com: domain of llong@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=llong@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739814990; a=rsa-sha256; cv=none; b=PD9+nwFo7khXUbRWP4wANblcQv88OdwRDXy5eDDH4Q0XxNB+664D1ZEFRRKfkP4wVDlw+/ f6L3oFzjeg1L2h5cJs/PkBL2Y93pmFEcQ2PueTEi8dlpWcKafPrsULNc6SvxVWF/+Y5+ux 9ryjRs8VPPAE+8Xi7XqR6jwh4Kzh/vM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739814989; h=from:from: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=niJ7GrqnlE8mjwkLXdroJsmq3cDp8d9woXPb/vSi3Z0=; b=Mdeo+KhAIkxykZIjwTJp4audP2hqoAAscrkKKXdwHXwwYpYxjppLz9mHdT7QEGfWc9FI5K 7koV/wN9vNemHP/Y1w6EHmojYHx1XU2wjnj95tzHcVkbCotPrxxiCZprNHIH1FkJdk2LkA B6JK96EPoIKuh4Cf6ZxcUsdEEiFCVSU= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-61-m6cveQryNVGDWH99goShVA-1; Mon, 17 Feb 2025 12:56:27 -0500 X-MC-Unique: m6cveQryNVGDWH99goShVA-1 X-Mimecast-MFC-AGG-ID: m6cveQryNVGDWH99goShVA_1739814987 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6e2378169a4so90712516d6.2 for ; Mon, 17 Feb 2025 09:56:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739814987; x=1740419787; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=niJ7GrqnlE8mjwkLXdroJsmq3cDp8d9woXPb/vSi3Z0=; b=lN4TCBMMTQgOxHSvOSb4EBT9xxGl/5VI1Jjv20hEEJlJzOzhyhsquvn0shsYvPgJZJ /6e5Vld+jtqs5ej5mw3gXxfiIbgYG0W2jvpfjYGIyVwr2gTODW/6NsWJzbgHqJngPFZw ZIqYwUSPqFvKYll/J+HASSrx8mWg+Agy4Fn4pH8DbRz7eDtERM4J1YQ55CJPFklhSZ1J QOursSTdU/jZH/LCf/f+P06SUnTpB+V543wKLEWp7OY2rjvolDngSaxXXuJ/DHOng6hS 52sb+IVpYB107xnPa0odtRJJ5TIGkIKuYJRg1QCYn4n3UPcZT4MkeC/BkYmCMYwuF6t9 tIXw== X-Forwarded-Encrypted: i=1; AJvYcCWbMR1c7G4fX+4ku9oKhpMGnMdM9sTMWnf/7c2z9YNpPPZf42v0RHmliBHxp03y6j58QdqDSR3lyw==@kvack.org X-Gm-Message-State: AOJu0YwlHmdNl3wCCiUdDO+fih/+53xgdlSIPRZaNRQty4+SJtBFmLcP xMUOZ2h6aFba0Z24VoccddSlj9yBDGDWD18G6JeUWM9WrxU+uiJbxm0Pz0QIlKJhZmbt7y0PD/g KtmcqYiIArXFjMqVi80haBtVbM4zZy/6eaSoX93CNnfy7zFp/ X-Gm-Gg: ASbGnctPpTegBbU2uLEPKostzgnztSt0lQxEtdhWm/aNCAU3EtoVut680AASECM02hy zOUFk2fxyh9mZmzSVrnzjG8YZvQ64hs+5Wc0CyJ8unAAXO/P2nd92N6x971tNLrpHfGARf8p+v6 RBrAvfeXauQhlcoZlqFP4CNf/eoB/V0dg5Hi4zsFQ8WNh61rV6V+a9ROrMLAJ06U1pjdUtvngU6 JzbrctH+OOhh2MUqUY7BrKG07DUEDc6d51n4DqNre4qrFtB/lvXJJ/MaF+axCKzLP4dXSLPSdii LsjbVdKMUru1O6Jqadx43cDbHkT2eZvYQx7fItUUymDeWcJO X-Received: by 2002:ad4:5f8b:0:b0:6e6:62e0:887b with SMTP id 6a1803df08f44-6e66cd29e70mr149586906d6.45.1739814987297; Mon, 17 Feb 2025 09:56:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IHMaH0te3WvqMwaIP410mOdgQto6F2VrfNkiVPnhvou7kFgzG16oJDSLaT8GWZZ/9EJy6ockQ== X-Received: by 2002:ad4:5f8b:0:b0:6e6:62e0:887b with SMTP id 6a1803df08f44-6e66cd29e70mr149586706d6.45.1739814987028; Mon, 17 Feb 2025 09:56:27 -0800 (PST) Received: from ?IPV6:2601:188:c100:5710:627d:9ff:fe85:9ade? ([2601:188:c100:5710:627d:9ff:fe85:9ade]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6e65d9f46a8sm54068316d6.82.2025.02.17.09.56.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Feb 2025 09:56:26 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: Date: Mon, 17 Feb 2025 12:56:25 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] kasan: Don't call find_vm_area() in RT kernel To: Andrey Konovalov Cc: Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, Nico Pache References: <20250217042108.185932-1-longman@redhat.com> In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: zHnFZhzXxeFy_PVpwOMgqf4UlO_1hy0-vrc58Xv0p1A_1739814987 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 8803A40012 X-Stat-Signature: wimxt54af4wb9sa9g6184dqbhgkg6na1 X-HE-Tag: 1739814990-316112 X-HE-Meta: U2FsdGVkX1+JOul9nAzy038+0nEtBwstRbrIY0/JwAiRolQ8y2YBWG0JC5Ku5de5C3ez0RrJiRRHqbc2EoeqUCZJxHbrZIwMM+CwX1BbU3M+7EGx3G0OEPaSxzRyQKJrqDJD5Y2K7Wlge9tlanrF2vjwyEtQct/j5mbRNXwqMWEjfzzNtkHBuIY46yCFArFrxgbhH78V8HIs3OAUDz9HE1w3TMwUwWKzKBZslu8NPK8MCrMcUdbNAtrvj7RRFGijQYOAZUdudKwb1qFBK7oMK3gI97A+FBZhrsSE0zDT+D7/77Zp4WlYG9DFOiG23Yej1AYERwlEZ9ggHTc3nAVgZ2P0Y8QsMLRJKNg02QDEOW44iuTHl3Ez/u6JJitncMaan2aQAxmo9CCK339qWyK9IvCUQ2TiFcH1hIntA5N0f7ZUoyylnB84M953wXx/5EowbK9/x7gU/+BW+gg8WWD2UMGhmtAxi3d3/8EBFAYWZ1T15iqo04lc3POU3H7afjPj2blFesdNZ+6bsJT0zAP3crt4mtgQZ80VUA6bDisRFvDdEHCJ6BmSkgqFe8/+3xXhUEWCwpo3LxImLgq+YohWJ+Vefv5Ohwbhmw7IWcn+TW4OAXWiNmzoZueBhqWnnSPDftwXLvNqddgq2RHKjMp8q5VMEPfYxczkkYG6i4gJsNIU9K5zycAuTwBy5m0dHxzx7+e6qfuEsT6m/35SHGNHHxP0TZpWVtH5a/Ke/saeibp53Untn1am85FLnfrVoo9TjsPrgTWrVZxndYY4CBe3GBiYxZhjluKHITGLpsu+q9RMUlGVY0cvtVG1cTUJyM/Cq09vxbcyaipr4AcN/uRq/1H6DPsMvDNkZ//KSnqn1q4ox9eYEdsYwqfkPyeDDgUxdsUAPDEG0jY8gTijIjWkovve5ukvXzef4ir/2/JvnloOd8j1r98M5BOvN7TsIJdj5+QiPp5B1TJG7uYhPYE 5uJLG+2S 1Ao2TzaVyXyu2e/aTxihcXU9Wt/VNvctUFbWPLB+js+itlDS4tgrQkMYQ1OdYK7Wn9GCDGoOMgbYWtuG6pc1wWq/BxIWVgWOdU6p4dP+PswI3IaOpc+dHCchYU9QjTQFqThgrYkZpcBEHw3gYhGLUoxnguToXQ33f1BJHhjsbgS5Dq5AUFx5to2sDd8aRLbK7l6dPKaYcnqfrroCthuPIsLQHZK9uySIGER5/DMesV43exP5Gul4HFD11AMtpMXHLIvphedhiiLy40qnslsRAzwRv6GxqrLSbwgXrcC412zj710lxr0v0zSAIZmSVjv0Q0Nk1UdZ5kczG7ziUtxyn7krJpvFwWRUapj7k+xR6aE5+ZCOy94TjGzuZGcFVTlDgqIfGD4MHMCpoxRRx2P25e5jwkdd7RadVNKISRXQ3eu4m8d/XcEyxtt1shD3SFQ0uMjhn6WWis72bPLeRSd+SNsGD4HreTxfk5i0sjx8u026lxii9IJ6CZM5LFTXisTPlNMrs4aRCpg5HBwxzsthtDpV0XqObD4hADwk5YJDJakEB7I8= 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 2/17/25 11:28 AM, Andrey Konovalov wrote: > On Mon, Feb 17, 2025 at 5:21 AM Waiman Long wrote: >> The following bug report appeared with a test run in a RT debug kernel. >> >> [ 3359.353842] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 >> [ 3359.353848] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 140605, name: kunit_try_catch >> [ 3359.353853] preempt_count: 1, expected: 0 >> : >> [ 3359.353933] Call trace: >> : >> [ 3359.353955] rt_spin_lock+0x70/0x140 >> [ 3359.353959] find_vmap_area+0x84/0x168 >> [ 3359.353963] find_vm_area+0x1c/0x50 >> [ 3359.353966] print_address_description.constprop.0+0x2a0/0x320 >> [ 3359.353972] print_report+0x108/0x1f8 >> [ 3359.353976] kasan_report+0x90/0xc8 >> [ 3359.353980] __asan_load1+0x60/0x70 >> >> Commit e30a0361b851 ("kasan: make report_lock a raw spinlock") >> changes report_lock to a raw_spinlock_t to avoid a similar RT problem. >> The print_address_description() function is called with report_lock >> acquired and interrupt disabled. However, the find_vm_area() function >> still needs to acquire a spinlock_t which becomes a sleeping lock in >> the RT kernel. IOW, we can't call find_vm_area() in a RT kernel and >> changing report_lock to a raw_spinlock_t is not enough to completely >> solve this RT kernel problem. >> >> Fix this bug report by skipping the find_vm_area() call in this case >> and just print out the address as is. >> >> For !RT kernel, follow the example set in commit 0cce06ba859a >> ("debugobjects,locking: Annotate debug_object_fill_pool() wait type >> violation") and use DEFINE_WAIT_OVERRIDE_MAP() to avoid a spinlock_t >> inside raw_spinlock_t warning. >> >> Fixes: e30a0361b851 ("kasan: make report_lock a raw spinlock") >> Signed-off-by: Waiman Long >> --- >> mm/kasan/report.c | 43 ++++++++++++++++++++++++++++++------------- >> 1 file changed, 30 insertions(+), 13 deletions(-) >> >> [v3] Rename helper to print_vmalloc_info_set_page. >> >> diff --git a/mm/kasan/report.c b/mm/kasan/report.c >> index 3fe77a360f1c..7c8c2e173aa4 100644 >> --- a/mm/kasan/report.c >> +++ b/mm/kasan/report.c >> @@ -370,6 +370,34 @@ static inline bool init_task_stack_addr(const void *addr) >> sizeof(init_thread_union.stack)); >> } >> >> +/* >> + * RT kernel cannot call find_vm_area() in atomic context. For !RT kernel, >> + * prevent spinlock_t inside raw_spinlock_t warning by raising wait-type >> + * to WAIT_SLEEP. > Quoting your response from the other thread: > >> Lockdep currently issues warnings for taking spinlock_t inside >> raw_spinlock_t because it is not allowed in RT. Test coverage of RT >> kernels is likely less than !RT kernel and so less bug of this kind will >> be caught. By making !RT doing the same check, we increase coverage. >> However, we do allow override in the !RT case, but it has to be done on >> a case-by-case basis. > Got it. > > So let's put this exactly this explanation in the comment, otherwise > it's unclear why we need something special for the !RT case. Sure. Will do that. >> + */ >> +static inline void print_vmalloc_info_set_page(void *addr, struct page **ppage) >> +{ >> + if (!IS_ENABLED(CONFIG_PREEMPT_RT)) { >> + static DEFINE_WAIT_OVERRIDE_MAP(vmalloc_map, LD_WAIT_SLEEP); >> + struct vm_struct *va; >> + >> + lock_map_acquire_try(&vmalloc_map); >> + va = find_vm_area(addr); >> + if (va) { >> + pr_err("The buggy address belongs to the virtual mapping at\n" >> + " [%px, %px) created by:\n" >> + " %pS\n", >> + va->addr, va->addr + va->size, va->caller); >> + pr_err("\n"); >> + >> + *ppage = vmalloc_to_page(addr); > Looking at the code again, I actually like the Andrey Ryabinin's > suggestion from the v1 thread: add a separate function that contains > an annotated call of find_vm_area(). And keep vmalloc_to_page() > outside of it, just as done in the upstream version now. I can make the change if it is what you want. Cheers, Longman