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 DDD67C83F1B for ; Wed, 16 Jul 2025 15:29:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8027E6B00AA; Wed, 16 Jul 2025 11:29:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B4006B00AC; Wed, 16 Jul 2025 11:29:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F1016B00AD; Wed, 16 Jul 2025 11:29:30 -0400 (EDT) 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 5FF546B00AA for ; Wed, 16 Jul 2025 11:29:30 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E6F01803B3 for ; Wed, 16 Jul 2025 15:29:29 +0000 (UTC) X-FDA: 83670512058.15.A0AC901 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf13.hostedemail.com (Postfix) with ESMTP id 15FE620009 for ; Wed, 16 Jul 2025 15:29:27 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=nF6poZ12; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of elver@google.com designates 209.85.216.49 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752679768; a=rsa-sha256; cv=none; b=7BuV85m1UvOTFpsnDa4q7uq75VMiGMhZWTNy6tTtVffqRkCgI+OWVEPETa2GXA2oWOTuh8 ZeKHsQremg7FlAgbhbVSm/oTZn7YWJgO1HkBcZxeoD630iBj9yFG/rFQs8FJpVawukD9uS z47+kMnCpV5ZvAMOSFo2O4hvSEg3RTQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=nF6poZ12; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of elver@google.com designates 209.85.216.49 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752679768; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DXRWy2GORatQ4WDqzRgN/A7GONpktQqNYMaPCTvZVp8=; b=mGWzQMIOGrZXZ8yuwsd9ussfcuMbo1Oh/viHQDdj6L/uTog63a7+xRnUImhLXQZ9bVrGOo kpsDYY358NfcQ/4eRv5dY27GUS047JW1ZK54Az5od/x47X7gm9U7qDKYpwjiThHtAT6l1f uJRjyg8pkfFlDelxzBtDO01zWI+YphE= Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-311c95ddfb5so38456a91.2 for ; Wed, 16 Jul 2025 08:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752679767; x=1753284567; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DXRWy2GORatQ4WDqzRgN/A7GONpktQqNYMaPCTvZVp8=; b=nF6poZ12NV+nTIHiSlH31JXgsqSvohrX90Pa9az+Y3mc5q4ElItpBV8i0nJQQtVEfc E4vrgq75yn+SXuF1jgBS6d+l0NMEpvDd9CuH4GfQ2ElktCWkzw5IaVKTkIipZcmU0AJz VTfeRb5FKuK1ZxqgqD8sJ9jIEQoWkcINFIXxpjN/+TMhT+aMAsKn696IJ2mmyBbjhQih zf5kdxBdGNU5kySdsIgnYQ0LySma8xEmfCJEL8MPWT2LgqxuhogOUprvH2OvMZ+YJg93 V4a1N+aOj156f5JM0lSTfPkgzKNKtlBzE67qiKVfuDm9znK6nrUoLe6za++KG6rvZn8w K9EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752679767; x=1753284567; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DXRWy2GORatQ4WDqzRgN/A7GONpktQqNYMaPCTvZVp8=; b=FXS0LF7+I6pUF0fjgM7Q/MdeAsotWv8HvvV/DYpCdLDEZaZNO7guHaGPPSRVJMV5jp dNkl5m04MZTJfJd2FhlhNuW29Zl9+NZFa3XL1WIVFRG5FipK296UffjHcIZOIffrQkSc 3NSi6KT0lQP+QFC58yUK5Xek3mYUeL30aIr1YPmh/bZNt/8rbIo+phu4HlwCFLwA2PWO txrAz6gj1yMK1ica/KljV70dLTSeRh9T4t6DYly1tx0YPbGFp011hRZ/1FfPCLoZu9a+ 6yibsg4NE+zAkj/djQkZdteUNP4rOCwfp226zEXwOh4ZjmALEWccdmPkehzqgJ0SL0oy olig== X-Forwarded-Encrypted: i=1; AJvYcCWG7onf9rvoUj60QckMzEI1qb+VdMYen1oORoKM4P2BAvtiXSYw0E3AL1dibsxRtmX67pRQVxL1/A==@kvack.org X-Gm-Message-State: AOJu0YzxK3/MtrpiZoNW/PMrlQPPSeCjEDmcW6rQM/eT5QUasHQkFCYM jDhNcM/UdlnOwv5PPTpwNsWEE/4XI4sjkbmps7fioNd7C14whEI1yodzaBiiIUTtMxvjajaVmYJ ZMQV9Yh8QlnvEBSHW0YXE9p0bTbAZb0bQn6fBN9Ic X-Gm-Gg: ASbGncuElGq7KmyMvyOidOYkOlYrPRKddAocrRmAmKeiMqaxaiJYeObEN3yqts6JAmg HjP1NMkpNkbekebmrVRaHsTHH3n7MBZ9ZAxWRv/sJZZfibkDRv6sxhnqikpNhJgSIFE/FO4zsqY JRi0QBuqnkpvUN90tqMfk91cwYRPBji/H1QGSB+j0L/AFPbTkAFgyA36w8zOqobBm1o3ZO206Eh 0XfNKd+C3Igks/QpQnIVUBMDknt2WchPHaLSA== X-Google-Smtp-Source: AGHT+IGhWGvZFIyXMBKollBvN/Zu57HCt2PgqO1m3mJKLcpRl1PPfnsYEt1KyZPLSnAw6C1O1yhlRpn8cRFq8axjCvQ= X-Received: by 2002:a17:90b:1c83:b0:315:9cae:bd8 with SMTP id 98e67ed59e1d1-31c9e76b79dmr4902000a91.23.1752679766392; Wed, 16 Jul 2025 08:29:26 -0700 (PDT) MIME-Version: 1.0 References: <20250703181018.580833-1-yeoreum.yun@arm.com> <20250711020858.GA78977@system.software.com> <20250711021100.GA4320@system.software.com> <20250713232740.GA18327@system.software.com> In-Reply-To: From: Marco Elver Date: Wed, 16 Jul 2025 17:28:49 +0200 X-Gm-Features: Ac12FXyd4otKpgnEaXRLmajtTI6ex6Uy6iZQJFcEjwrCoLj_OCKFTg4M7FvyGmE Message-ID: Subject: Re: [PATCH v2] kasan: remove kasan_find_vm_area() to prevent possible deadlock To: Uladzislau Rezki Cc: Byungchul Park , Yeo Reum Yun , Andrey Konovalov , "akpm@linux-foundation.org" , "glider@google.com" , "dvyukov@google.com" , Vincenzo Frascino , "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" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: fqumbjutfk9pjki5hynwp4y1kr8bup8w X-Rspam-User: X-Rspamd-Queue-Id: 15FE620009 X-Rspamd-Server: rspam02 X-HE-Tag: 1752679767-438631 X-HE-Meta: U2FsdGVkX19CPmXss+lHjbjSEhggo8toEu2NVfGJwL73C3cw7MP7HvoLxXdwuHZF9HOCE/CVzhFeZHplAOWYB2wKD3bPr7FJ1b5CChL1fTzH6EqiAMjF9oa9JZj0vFLfGQhGB+qe5Dm1JdfA+jyk36xOcspeZ6uJUipz/bAFI3apLM4XIbmEc7KwGHqDIwfGMotDG9u8Lgrc83GQAsbHv07nmVe5MnEYwOoaG91nY2rFF2bZbUj/vft0QbTJH9sImFDPEClxJKIOJyUabaOsZ/OsIDrA/JbZFhHfuO+6bi23EMCQyvC+W5rvfazAQtNIEO8FbV4r5HE4y1/dm5kFRl7J2nn9fd6JmELAOhqCsp5H1NAoo9xbZMfnM7TpRj6yDbp5oIsvitc/LYgs9Sm8fVUsVrDg6n+8CFumVSZu/BHveXGZnXbdgqGUIHw8D0wAUiRhA2huYwXR8Kur/s/Sn7YkrlP5RudCEfkG75CYHZqCW2spKuprYTXGCUNUGHkxIo0Lmh/mLzrZFIap38DwXWbxUEAq8NZv3vuhgNHax+cfm9uupKZnczSwgno4jhWj/MJ6OrcRN0ZGFm4TWTNI0hzY0KhdwFYUVYHwbh5th22K1OGeLHnLzlio1FUfUTQhi0OnkMxScQP8UOfXwkyX6rmY0CjNXJe3n9rcTChTbE21cYY3V8rkQJRWK1UfaXEFpbQzlQpGfvQ6Ss8mKDYNqAGZTWi5DVxyAR/pTHPbskRF3QeWp0pRziBgQ2Q2T8CnE28HgxXJvK0TYnDzG7c94viPwIZ1nVQgN95lvEXBpjLjNM5CkmzLXUVAEj97RlopXaO1+v87jBAWXvTfd4/HEH+4OraLLM8stavr7xuk+Th3IkkY/EKWraEdX4XS1vZqcJZ6qeC95RZqH32tGnwgS7Bkf8ZGzDEVDxA3il9Lpc04plCQuVK+ZW8PXkmsLVFd3VRWfSLtkn1Xhoz3Su1 02c1EEFi fYmD4AnD23xnjF7ZdIOd9E9ebgd/9rEPe1OLeJUnu6dsNztB+gjb9BvbaRqcs/JSUBERtWuQYNCe/RZVwEpAN14M09h8kay923zQqwzE0eGFuJ19FKtkmsHSst8t3D9McuulXV8nMcryBLGS1zwrTIDJNT0UePqObWkUu+WaFk4rZFrprKcWdpgGj/JKjeTmbOmAXMSJ9JpI73hrVmTrmZ1o1Kcb+xYUlBAQcknxXUI6tNt1Zk81lt1BeCCsE9kxc16IzQ9wapGcD9xGBcwodFRY9hBIlzbkHTL8iGqvg7Y0CMq9CcmQDFWscurN6rQgchj5rZbvCi6rwRmng2nPyUM5qiVpmt6eBTw4h28qjMKh0eWSO3/jTyMlNzNKJq+A3leoU 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 Wed, 16 Jul 2025 at 11:09, Uladzislau Rezki wrote: > > On Mon, Jul 14, 2025 at 08:27:40AM +0900, Byungchul Park wrote: > > On Sat, Jul 12, 2025 at 03:46:10PM +0000, Yeo Reum Yun wrote: > > > Hi ByungChul, > > > > > > [...] > > > > 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 don't agree for this. > > > since in PREEMPT_RT case, it has the same problem. > > > > > > In case of PREEMPT_RT, spin_lock_irqsave() becomes rt_spin_lock() which is sleepable. > > > But, KASAN calls "rt_spin_lock()" holding raw_spin_lock_irqsave() which is definitely wrong. > > > > It's another issue than irq handling latency, but it's about lock usage > > correctness. You are right. > > > There is vmalloc_dump_obj() function which should be used IMO: > > > pr_err("The buggy address %px belongs to a vmalloc virtual mapping, dump it...\n", addr); > vmalloc_dump_obj(addr); > > > we use trylock there to eliminate an issue if invoked from the IRQ > context. Something like that should work: https://lkml.kernel.org/r/20250716152448.3877201-1-elver@google.com