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 78DB6C83F1A for ; Fri, 11 Jul 2025 08:54:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1FCE16B009D; Fri, 11 Jul 2025 04:54:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D4206B009E; Fri, 11 Jul 2025 04:54:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EABF6B00A0; Fri, 11 Jul 2025 04:54:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F22736B009D for ; Fri, 11 Jul 2025 04:54:39 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BD3181A2C89 for ; Fri, 11 Jul 2025 08:54:39 +0000 (UTC) X-FDA: 83651373078.03.1C23517 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf04.hostedemail.com (Postfix) with ESMTP id ADB184000F for ; Fri, 11 Jul 2025 08:54:37 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=go8V1JqF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752224077; a=rsa-sha256; cv=none; b=oxtxHuhB+iUTKjOdiJ+fjJv9CqT26rA9JSauh0EAt9tGF3+9ixlxs4i6RsqvGxcTIHYqOo VqNwWF6phrOhy5qsIdsOngUyrUyDG0viU/LmeRBhNAA2GRzftvzOAMWJsGMz8NJha0EYdY ji3lIpwaSaw+9QTrgNWO7Vgp0qhLemY= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=go8V1JqF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752224077; 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=ziEQtJ6TzJ+Y/Zcb94FyvvcznpnXNVBhWXC9sDmSYV4=; b=HJfPEyQ65sXCbwwWfdHZMY9PfchX67JcuFZjKffT3OVtcuUDQGxAe1rOdl+8y3r2ypslur ksW7HPDroSu5SSbQcj8hT0oGpPPXOotCZJktOTXN2Pft//gVUzZaaa+WCZx7HbaB7nOB8h TYq+dPRLIc30tBK1hlRPJOYxw6FUa3c= Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-553be4d2fbfso2088789e87.0 for ; Fri, 11 Jul 2025 01:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752224076; x=1752828876; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from:from:to :cc:subject:date:message-id:reply-to; bh=ziEQtJ6TzJ+Y/Zcb94FyvvcznpnXNVBhWXC9sDmSYV4=; b=go8V1JqFFQFqDxn6T4xHZfvTCYgfU9NctlBWSX6gYXi0ZSFj6FWQHN94BTxlROWQ0Q hfF3l9Ax0M7sNm+W5bUoNRmeQv/40yC98yB5NKHpD+hAovxd5Yc2cIcN39ms7Az8r30n RXXUur8z3rZQIRQJvTXcmSRa8KpDhFcItFyP9BYkEKFYghs5gnj7QgF2yC2xqrxbmK8p bxvhmPZCDH4aKppbBJkkrAjTOmcExK5zqKzYIgCIanB5ateGad8MQ+p6Tp3+Kp6rwrrB wEI2qtoDf8dxbWj4JzW20o8Wvp3tPuZtXYWuwwTNuMDdpaQdeLJa50ce7piCbcAppFFd jMlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752224076; x=1752828876; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ziEQtJ6TzJ+Y/Zcb94FyvvcznpnXNVBhWXC9sDmSYV4=; b=pfKXxo7Oo9KaZLWqkmWMZLtauLuDQ3HPVjaxI1u8CIKo1E3fyY0gjxoeCSvPUm8djh cKFD6gQhSnuJy9nbG+eIwoi4LO6f1TdyjCIpMW1viy9AYE/qEWYLyWyZgrHw7izcVTmN gXMjYKdOEo/v8j4n7ugJklA2YEQBu4OjsWW9m+4OshZuSJUlkJOBwVKao2F4+Ys3YP2q x/d8ZFqOoindp8AOtAa7oWm21Gnr4g8oH3EVpoA3oQBgAUmA4EJ5bRsOvX5ZVzjoJk5p gfRgO7B+LUsu0EdjhGQL5T2iTYBZLX7+zLRVf4r+9UlImWyO7Pfu7AqLwVtfAn8K9aZ4 Ptgg== X-Forwarded-Encrypted: i=1; AJvYcCWa2uoLj90VClU5y2PMOHv/i/h2iIbx4Y2ona05f6GuWAWRkWib/8NbZCJxq2UxVlxu+p/jOg6xNQ==@kvack.org X-Gm-Message-State: AOJu0Yxv2oo+E6iSKrObX3bGVwZPEy8BCgoex/wrdDV80QCsK60hqQhL Wi3cOKyuEwIJ/xBWi32JpHPcQMLJ1+iUOzC96+FWw4JL/ymdw/ZlEg1C X-Gm-Gg: ASbGncsimo7nmx/tWWYD5abLD9wTfh/YGsqXJSHYOTzhG4TKkfD0GMmRPjohHqCDTh7 0FC9CPBi01QLXbDSpIaHaBxYV3liqsV2ogPRQk/V8aSCeR/rStXw8W4WC/diCjP+2Fp0lP1Oldp EbUZgB6UGHDdwOu5HuUPcRyb15QcJ6mzXDybfjrfCVbl5d6fusxCF/IkMJlJCJHTh4pdvkOHl+o RP1BT6PIiPNnTycIgRLjgdUvsBtM9Y0I4mo7Gu+98I6xdKfvb/2FL55o2L6RSQmyVPo2uWFDuZo 0S8eWyLCm/cvoNc2n8BVtSH/4lkHVKwMeMFmXeKKPkI8vy4sAbhS9L9NFrcVVY3PbQWTtQaAC9q DbsCIrZKIuuRmeItRhwZthSzBHotmBElUq1qo3jfZgfclQISOFw== X-Google-Smtp-Source: AGHT+IFPqpkRmTjKeGpVvTou+tnFlMgMi9ZNeCVtfH9Y1Rk4EXvSbZNZFUirIWgtanrq34tOCvqwWg== X-Received: by 2002:a05:6512:e9e:b0:553:543d:d996 with SMTP id 2adb3069b0e04-55a04609b15mr657418e87.33.1752224075346; Fri, 11 Jul 2025 01:54:35 -0700 (PDT) Received: from pc636 (host-90-233-194-86.mobileonline.telia.com. [90.233.194.86]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-55943b7a6f2sm820437e87.235.2025.07.11.01.54.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Jul 2025 01:54:34 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 11 Jul 2025 10:54:31 +0200 To: Byungchul Park Cc: Andrey Konovalov , 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: References: <20250703181018.580833-1-yeoreum.yun@arm.com> <20250711020858.GA78977@system.software.com> <20250711021100.GA4320@system.software.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250711021100.GA4320@system.software.com> X-Rspamd-Queue-Id: ADB184000F X-Stat-Signature: 64im1yne8kzdwww3iokkd5gje168maoz X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1752224077-550164 X-HE-Meta: U2FsdGVkX19x3R78EdHYh9YK1NOL+C323lhUyA0sFLjbZDZ/qr0FV7BnQIBdD2XT+CZ/sB7LMTAcqo/TMDwCNQaerZso4aPXUwzPq88v1RozFb7MsAXjg64KncRXbujQzD19clsZ3xqvs99KPuirhk729R8U3pNlsMFSNIEww5dhqurtrNAv4v3KeOPJ4XGQrpAwBvB5gviaicrG5T05KwWAdARM6C3lJLfE65VgB9/UIfrA2yw3BPLEQiXm5itspEnFp6y2mPpA2aZroHXOX5FWZ9C+pA2xZ8g8WvkDHF1GOBH+4yONuOhKcHfQINWIor4HGq4bqI8n06d4fbl6RjIJPTyQbW0JY0+gSkatVvor4TuxOzHJ6c4UT7ovyQkNlo8t56ilE8j3ZHAN+yOFvlSDhfetKWWpwuU8K6PyWipyXuWXb7/ovMQjEruo/MxJzAZk6IKU9PBD9I+6LQVjJiQfZ4PmeacQ2qCX0iLzc3SgLtKsNjapRCxPdHmDHdNnQT/+q5p8LzUdbqksJ6tkOF2WteYlpuE0QxZ9bbgLZf/X9OMfCCrmxc2wRN6VFumAnujFHnWAVMOWRRzgz6IDXZWVrczCSb2F7tfFrQqXxEVxaHgUx/fDrZUiYDpX5ysyWEjAuOY/kv0caRegt49FKIZ6SdyRpdIt7yrlW7c0NKUwaKGZhfvzd3Wqk7gOvnHfQEuPAwPnYvrBfzBBncCz0q+WCrgo/dDSstPGA5n6Y+859BTRU9ZmRfx1tnVzag4wE2Xj8DJc7DJbDhNtawQbPPd4zNFLn+ftXRucBYrYGehhBabab4Q3qH5C5MC1NNwfccKTIQO/Ydc3ZV1kQEXvATGDWy8OKd/V7zqtpS4pw0bgqegToeYlwKDKdIF417tRJNqbqJQ8T2LS0kGYu4rj4VaZ6UwgHs+NJsyVIvTLvQpFPUMh/QrXjq/pau79/322DOYhpcxiw19QDJJCX+t YbF5sf5M MozLBUHc4diIL/W5vaD+2W/JUCN5oCJufoRcx95wVdiT04UszwXgJkBhniZaTnDeh+LfuxEVm+Q2zGHw+fBvAkr54zSww7aTG4zUXFhuVqPK9DeY5SsFQmnvy2Ye3OrL5Lz1ErYsPJM04UM7f7n9uvdcd9hRYAQE20L+8dRyQfTc8pux6VxWzVL83gyfKQKYw/tRHxgFvsUeY8/gWXFGokQWTtUAF8LgjQ2gKqGTurjM1SKRmWsGZ1KcckZ/aS7Tvulotu6J6QkxZJ37bMU0rqteU/TY0SV25SA8/nrui11wO2cNCtW7xOO/Quyvny6sujzA2ZZYl0spSF6ao7DCLTNaCMEFU0j+N9lomyvrr4OHL6Gb6cqspYxiaNqikkGe7Bq7cPNIQi/xl5kmuZNUgY59EMQ2i7VfZajTeI6D0UaTzBnyQGuYYqDWiNSRwG8Bw/1Vvt8Db/IU9hoYlNv8uLC8qs6xujbzdVQqMoU16lXv/EK29fXeGBKwfbbjDScPVfdH/AnFfZjP5GCX7mmGi0GqlK5KYx4y61BI2pFgtxh+JOn3+SS/MDuQ5baehVHpH3NVhJtEgQt50HNUd0SJFOd4UVUFTZ5jVlplZgtPlv69+vXNhbgsTsPp3svesURIBpXtswY/d6NuK1D4eSR4aDP9U5QNlw8fNbchGoUQ+W6gSE28= 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:11:00AM +0900, Byungchul Park wrote: > 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? > > > I wish we get rid of using the find_vm_area() from already existing users including KASAN outside of vmalloc. In some sense it is not safe to access a VA because of "use after free" issues. -- Uladzislau Rezki