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 3A7F8C02198 for ; Mon, 17 Feb 2025 03:29:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 95BF128002B; Sun, 16 Feb 2025 22:29:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 931A628002A; Sun, 16 Feb 2025 22:29:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F9A128002B; Sun, 16 Feb 2025 22:29:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 62E5728002A for ; Sun, 16 Feb 2025 22:29:56 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id BB4F41418BD for ; Mon, 17 Feb 2025 03:29:55 +0000 (UTC) X-FDA: 83128007550.14.D256823 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf18.hostedemail.com (Postfix) with ESMTP id 549A01C0004 for ; Mon, 17 Feb 2025 03:29:53 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=E0tBJOOT; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf18.hostedemail.com: domain of llong@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=llong@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739762993; a=rsa-sha256; cv=none; b=dJGET51hUDRzNJL4lDS/gEWCkE6vyf1v5XS/+1IMHET3fJbi930X5bluharUMmXq8Uc2bi sZiwx4dtVCiqjsVDPVzofLGl9O9k+9HEpt2Fhi02U8OwGFRySzIfsilI1fQTdagqYrQm9i F46q0aGhaw3t+/obraWX9C1+8U7LMyg= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=E0tBJOOT; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf18.hostedemail.com: domain of llong@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=llong@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739762993; 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=rWjuYHFq2b/x6u1PpE5bTN0UtHhvs4sXiLszKZ360YY=; b=svbU/h/canzqKYQ45LYegqhWGvUtQGw8wEAH9SO/7Ixm0QrtNPob34WE/iqFLHLghNTcOd KTa482GHKSU2vQaAxFOfrWJjPbmwkfLhF1K0D5SAxfRz1GRS3EEjTOk66g2XoPD4izVBs7 C8GWS7+lhy/8Lco/YvbcZHF5SiT0SWA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739762992; 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=rWjuYHFq2b/x6u1PpE5bTN0UtHhvs4sXiLszKZ360YY=; b=E0tBJOOTbCyT74Z0T9378IMl7gOFQG/JMB+bqEp0WiFTWaHVPSP3zyigDtthsjzimEExON Do2fwGkfJ8rp6QaOtb5aW2xYcQPmcG1SrEDyAyQFT7/Gol1GouxdobAerznS0L9EDYB1eF vjVyy8MfYDKJMv2OaP7L0jF3mOXrpzc= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-369-rx2JHmJhOim6EEtE4mBYsA-1; Sun, 16 Feb 2025 22:29:50 -0500 X-MC-Unique: rx2JHmJhOim6EEtE4mBYsA-1 X-Mimecast-MFC-AGG-ID: rx2JHmJhOim6EEtE4mBYsA_1739762990 Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-471cfa5c808so106360981cf.1 for ; Sun, 16 Feb 2025 19:29:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739762990; x=1740367790; 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=rWjuYHFq2b/x6u1PpE5bTN0UtHhvs4sXiLszKZ360YY=; b=VUezs40h6y7e2HJsdow5heGsymgzF8BHCPeqNpoiQGNrzdf9QuQKrIEL6wCuIcX+MY Jk22l+taveZtsd8sgSlY2iomxcnO1ibhRqEsjGlnDTNUdcOJlWXaLdjQds/xzzP+ofMd 8cmPpVNloHA/yuLv7Vm0wnSdeqH+Eq5wZTBRQ6FdYZcg+zOHRmmbTxaQ6FLIRudKfZCO NvVx3J03OPpZa8HTBoKxexevRWVkQK4/QKuOPzwMxkZ+dm1VN3Y198H0aSa6bHN+LUdk 1R/nd5vB7p3tUHmaleS77xdz7UsYYS0YKPKIR47UOi5nDkWGvCDpAuDtFM3qOxlEeMIg J0mA== X-Forwarded-Encrypted: i=1; AJvYcCV9KrxH4Kyomn8wnwZmt+VioZ4w3hOEn2jQqzWgKAIfW1tpfOirKf3TXM1PkM1W41DOvMgCzwgoBw==@kvack.org X-Gm-Message-State: AOJu0YxXsNk2zmbtRvUsqkaijWGj9SmTOlfcSxruOvyf1aXMogshMxl9 XjCEUYdyoIHJkcEsvR9Xa3UcAqhoYD8//KC97u8uwk1trvr35vzSZ2nsjRf8Egw99jRsArmuzIL lpOZr5HThF6J6rZcjIM3YIvL02K4PV/6hjz8EjZUHnQV+zpqj X-Gm-Gg: ASbGncv5YVP8uUB5ZnJp8alJbpBcO8nwfhfoG8iy4gjqeDPdmRwbNQIAn6S2qkORsnM G2GZotcMRMTihc6vQBdXRHhiL5NneVu6qqpkbX3CWwKrD75v4P/ydDuTSWnjhuVh7pDSpTH7qMu zpSYdrrl6XKkkqEyVs05rDGxCuXD6fA1kQywmUTpBBnV9r2tdpk2K0tog1HJCS9m6eY90oGhw6t qnWD14608pD4brbThoVKgPJ5ff0noF6j7YIklkbJqF9LgMdY2zUkDeOooJ/BrEbp8rQL4fkCaZV NexVGYAkqJUjUS+HrEMOAvwhfdWGMCVatnnpo463Pd+qyPlH X-Received: by 2002:a05:622a:189a:b0:45d:8be9:b0e6 with SMTP id d75a77b69052e-471dbea2921mr114809131cf.43.1739762990398; Sun, 16 Feb 2025 19:29:50 -0800 (PST) X-Google-Smtp-Source: AGHT+IEhaUXlGg7cIskye7XTwVsnaJVsOtdLiD/L3ISxp1SgnP95qHJjIUbymmMZLfOiirIuc8XZmw== X-Received: by 2002:a05:622a:189a:b0:45d:8be9:b0e6 with SMTP id d75a77b69052e-471dbea2921mr114808981cf.43.1739762990094; Sun, 16 Feb 2025 19:29:50 -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 d75a77b69052e-471f1e866f4sm5639761cf.33.2025.02.16.19.29.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 16 Feb 2025 19:29:49 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: Date: Sun, 16 Feb 2025 22:29:47 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] kasan: Don't call find_vm_area() in RT kernel To: Andrey Konovalov , Peter Zijlstra 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: <20250212162151.1599059-1-longman@redhat.com> In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 0yNkVa2m7FrTm24l_l1iXOd9mc0jyMwPmkiMTdQvTPI_1739762990 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 549A01C0004 X-Stat-Signature: xtcfaxcgoshp4zwdpbcehtxxaxu3r9hm X-Rspam-User: X-HE-Tag: 1739762993-260215 X-HE-Meta: U2FsdGVkX18E4hTvtWRdx9m0/2bIyB6GPtTdUNsJ5ruY6PR9ZFWPvVuqYtVhjiMdpVKWdU8pnsuCxiDpB9xL/arLdypHNRc1hgqiU+yxL6mgypvvlkChFGR28DCSHYEytSe3EbpJCv7bzi9m0yP3v8SjjhTVAJeJQbDy5OMJjbGCA4apfzRMm6Ojz4raVo85IVMOvMEVvMCR81rhSGWCSYHfB4P0MU76XRMJ5YSA89Rf00diJpwOnoFdoR4gWfuKHhphYLUd0gmOY31FznWwqNNR/UQjY81MEVuZbPSmsDT3MHWxzexw0QQrKg6NTxTcofCJLhsbrdCkrLa83t0vlAinE4JmfMkI4QUz2XhsL+hBYff4sgFzM9PC/RfCMLlXqSOZtURXpqlq4JG0AU0a28u+mXl/ZDaqKd7oz/pyFKu1KPGrTQDfruRwRuBE/4UgmpVom83SLlarGTDdRDWdA/dUvMtMBsLiMji0XskKL5sI3iEPqXSWAXUXxwuHLk0/KuZUYM7ojEk53PlorXGZO9yYZLTenso7jiJLdWUT9XAS12RN/tPStIfGRkU6sXJ2b1URclUVFIh0zE59tkD+xiaxp+fIyFj2D/rVZvFLBKL/z3t70sD5h1IoSnZj4UXsNxRmeopTGaNzs4JqQEdzRcODMPXOK/H3qY6k5kZiVepdMXNlGbFa4zSW3VrCQ+H4Mj+CuF2y/CY0AMHR3MFmrvpyUIS5yGLIn8fkaJNuDR2yZl1cSNZ6GJVgoFVivjbRZXkqQenVJn+gzE7rQW/uIGX5jJe54sOBPiNIRJ3z8R/V7OWItmUvqixRy1nTNs1Q/dHQn9PNjfvqNczg9wxqFb1UrjRfk8d1bKOwKLcjhgMSx3txFIVNIj1H28hLbWdYYEYb1fU5cRCRW/P5AXxtsKIORPMsxs06/7xXWnQDizLpFQvYNt5hoh95dZzpZvcp+yxk5VlRMLvo+hZAtd7 N/8903WX d7ppRAJzODW+Mfn2USV1xw+pAIOzDrfm1JvZDq8CWCxb7Crxvq6b/GkD3mUI40Qc8ZVfXyu6Ijb4YI4qj0WLGybx1e9/cMiGtlQlDdaylKGBudjx/MXhX0ojt4j9gE1R2QSGeFxni9iPHFs+n3b5GR7hGKHqKzJT+QdtB3V5byl4oir4h/tHr02yPtEKB+6MwDG44A7TiDG6Ge5RQh/pBh0iTGLNiVrp/5dRaUdV9xWmCmNdlL+3dfV01qszTl7/yZ7BbtM73/59UtAgxCvC937nsuENIbj0pI9i6Vej6hGElFJyO0PN0lvJt+mKO6Vs/6L8jDC5Hyw210sWCjUph8pidvlm3mW1+6LkA0HozNkfsQ6yliUcX/NLMruLQfFUQCgpSYNO4g2tEH0ZeZIisDVgDTrAZuM9thffceGIBhFARAC8wZx73z73zX+d4osNFYmP2NXADojvGIaH7yolrPT3fvvxTMvgOrM3XpJsGNFh3qxkONt1wi7fW63+rjn60I9pcHdSIFzk65jn4eGvWcfHl01P1PmhYei9kloR4BmRkLsw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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/12/25 8:48 PM, Andrey Konovalov wrote: > On Wed, Feb 12, 2025 at 5:22 PM 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. > Would it be possible to get lockdep to allow taking spinlock_t inside > raw_spinlock_t instead of annotating the callers for the !RT case? Or > is this a rare thing for this to be allowed on !RT? > >> Fixes: e30a0361b851 ("kasan: make report_lock a raw spinlock") >> Signed-off-by: Waiman Long >> --- >> mm/kasan/report.c | 47 ++++++++++++++++++++++++++++++++++------------- >> 1 file changed, 34 insertions(+), 13 deletions(-) >> >> [v2] Encapsulate the change into a new >> kasan_print_vmalloc_info_ret_page() helper >> >> diff --git a/mm/kasan/report.c b/mm/kasan/report.c >> index 3fe77a360f1c..9580ac3f3203 100644 >> --- a/mm/kasan/report.c >> +++ b/mm/kasan/report.c >> @@ -370,6 +370,38 @@ 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. >> + * >> + * Return: page pointer or NULL >> + */ >> +static inline struct page *kasan_print_vmalloc_info_ret_page(void *addr) > No need for the kasan_ prefix: this is a static function. (Also the > _ret_* suffix is something I've never seen before in the kernel > context, but I don't mind it.) Sorry for missing that. Yes, I can remove the prefix. Will post a v3. Cheers, Longman