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 6B3ACC02198 for ; Thu, 13 Feb 2025 03:00:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECE896B0092; Wed, 12 Feb 2025 22:00:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7E216B0093; Wed, 12 Feb 2025 22:00:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2AE56B0095; Wed, 12 Feb 2025 22:00:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A33FC6B0092 for ; Wed, 12 Feb 2025 22:00:37 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1B17F801E9 for ; Thu, 13 Feb 2025 03:00:37 +0000 (UTC) X-FDA: 83113418514.06.C89401A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 890B31A0011 for ; Thu, 13 Feb 2025 03:00:34 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bD7FURvg; spf=pass (imf19.hostedemail.com: domain of llong@redhat.com designates 170.10.133.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=1739415634; 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=OWwww+9wjYnmYiIoosHtl2D22JscWljOY5A6wHcnvOU=; b=kX68BZfWo8Gy1In3Gq731V5VR/colyowUeVT6eFiRG8bB61LBoQmc6VbC8pOSIOLEXqrxP PNSOvmy7na7ERVuIKOQSDoE7EsGdmYMZWqCAG3yQU8tySUXkTxXIsz/YA33XhjidJu4MFU vrFJ6qKZBGNVBtNuG6vsbnRvAmZ7Tw8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739415634; a=rsa-sha256; cv=none; b=uPPZvmbgf1OcEr2fF41vpW+5mBAk4Ps6GHxY7wwPfEHvmRyG5VUaHLZE7UIBY04nRrpdnA nSw5kbxv+Um7uFjtxOekMZqo+z+9yYkNrq2Is/5aonBuxsMAgTp3kYj4HjMB1AIPZW/bsc vTecuul/l2ePrTn/sBttM/IcjzCNlEg= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bD7FURvg; spf=pass (imf19.hostedemail.com: domain of llong@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=llong@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739415633; 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=OWwww+9wjYnmYiIoosHtl2D22JscWljOY5A6wHcnvOU=; b=bD7FURvgrjzp633QYY7URfDn7UZkR5XjrzLNjumuvP9RuGVRJv76bnVtArv4ktfuk6y/Df rAF2umhOcoLgIa0wmU6pVc/4Hh0VjBBTQDr4gQPSCpJ/abiHDHhKMTOUSTenjpxcCE+sT8 VCbXWaRSEm08BOkGP+3ezarYG2ITgxg= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-674-19rRnwWNOuKYtNuqwoyv_A-1; Wed, 12 Feb 2025 22:00:32 -0500 X-MC-Unique: 19rRnwWNOuKYtNuqwoyv_A-1 X-Mimecast-MFC-AGG-ID: 19rRnwWNOuKYtNuqwoyv_A Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-7c07668e74bso99494985a.1 for ; Wed, 12 Feb 2025 19:00:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739415632; x=1740020432; 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=OWwww+9wjYnmYiIoosHtl2D22JscWljOY5A6wHcnvOU=; b=f/Y52m1M5h1VNdeDTu2SZhtl5G3NQfUFLK0kaNKqQUReHdjGrOeQ0jyRzpzOZIH+/Y urYA/rStN0OTePsBfXt8qpL7D5RJEfk/450tDJOsE+xhp2oG3TshzlOTrRuZsNVqlnAd LD6SBUE7vFI7eyTuQWLxDfqjzXYhYpUjIbYezbx/s7eairqlI9ZKjr+EqUtXUwvRWSqq jCB7QpeR/j30d+4b+qYQ+0T+A4eQ1RXKnaCw/YeQTDbI5MWxSswmbqyI1hDCCYam1yes IYUA+sHt+P/KWQ90PL0KRj2kkaEeoxdj0xH8hY9HWnzfyLyl/XiyJMSmMRVzwLEdsve1 /ODg== X-Forwarded-Encrypted: i=1; AJvYcCUtVyKg8l4nZPdGyIEjrVR6H9ydpb55kPohsF9LuZZDPVS/prz410XgSsFHa+HCVnVOEw/T5IMgFA==@kvack.org X-Gm-Message-State: AOJu0YwnYXRhKMm+NYaswTBXwjXiCNBGDvLuiMLsoxR27skLqkqgys78 dtqeZbuNc306gDbEvHeOkBlw0gIZ9hVQvCgKh3elVmF4gw/a9CBsGwdSzdvV0H6y42gVWUwzHcK X0hTv6GAnWuFPGiEVXxQ7z1HdIMtoWIl8VBTM96QGsUrMlBHL X-Gm-Gg: ASbGnctm5KvzLnQvKPx5uWPr6Wn33ewfq+PrA3YOxKDTDTlw94RlL3ZmplhQBxP8eIB CFAEJLIgyEzKhQ0i9u+Owwo68UIjpHYHNsGr9INL5/y/RAw3Dp00Ea8Ze7WMvHN73zg+6DEKm80 SXvkgN2OiummiNym9GGAdVlm69+4Gkj5PDW8P6svXWupFiSiq0miC3OD3w9SyPrHy/YlfuppSfX Hj3P9+XVNsubFJ5ExDn61pmEP+msTGGhWfer+5/EJggZbZndSUmwhZUEqzDME6wNlnvIWQao9eP EKj++APaYL0eP+DtJ9XF5eyG45eYyO7NPRqA9PeHtGigRVXS X-Received: by 2002:a05:620a:4154:b0:7b6:e47a:8e1d with SMTP id af79cd13be357-7c07a14eca8mr288913385a.31.1739415631955; Wed, 12 Feb 2025 19:00:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IHrPdXEC7uKTGrnTsRzg3yFpGic5d9M8ugrhFeLTyhpIMQ12jCFsEbrGCa3smwHMxU+LwNpWQ== X-Received: by 2002:a05:620a:4154:b0:7b6:e47a:8e1d with SMTP id af79cd13be357-7c07a14eca8mr288908485a.31.1739415631630; Wed, 12 Feb 2025 19:00:31 -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 af79cd13be357-7c07c608269sm26919485a.31.2025.02.12.19.00.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Feb 2025 19:00:31 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: Date: Wed, 12 Feb 2025 22:00:29 -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: IX1OwyNyAaqzHOIh8BgJFmSoghIF_1wgaT7OFLJgFuY_1739415632 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-Queue-Id: 890B31A0011 X-Rspamd-Server: rspam07 X-Stat-Signature: c4nk7cbgc1dypkepscomgwy9b7i7gcop X-HE-Tag: 1739415634-245391 X-HE-Meta: U2FsdGVkX1/TocSIDIECXp5WmLVdJzOn9IWRRw4ob2HNn8grPUBLwz616vvM0FFl8hOhlLfzFwMmyMWPMGyY5DHUiBA12ugrZfDwQxXd9MfK9p6CJymEiirbr20VseY/L5Mcxwlen5V1X7LrArStZneI5UvK8lT60MgGQc/6QYFd7+OUNxKIRhQbw5Ac3kp34micwOmbaLgtAIdcGw70e+uPT02E7BQnLiRpFZbXt3jOlvCdX6Y0fPE59SR6i8sKOC4z/3WUS1MNXRuosxZk14qbW1JYzs/MPwA8Uy6NVPspHnppk3BzGJ/SF+DRbXxMs+J7MstiNvtHj7u8hQuTOsdNyg5cwcJAlDyiRrnL1M59RUkFCsA+deTKJt2U6ftCuq+3oAZppApo4T8ZFGg70QiJ6esCWBzCKKZ06iupdYE8Sg5/Qsrsi+O/ukDuU3b8RsCQqPeXjzjXc4K2dQe1afhkKobUntuAv2N9Fsbub0EIra2tkoPGM8XfwF38Fj5mObic6Bw075cxomR3odjGKr2otfq6jh5//lXndbqFDpdN6AAKZIb/KFkLM/5sEA4/FCUaDE/b2fy8nMrBnGIdoCFk8yLiLbqjQx8ekxMLlnhY6cQh1wr8ad6ROtfn2LzM+JNl41EJJC7RB3nNOGiuPBW72rHCQRbw1IuMbv8fpWI+HuHMeTvNaV8zfbqe2c79JMP99gfH405O2eDhb7bVQ587cXF38wyaWPiQFNBGJVyaW1+ve2AZiiC+oLlX95qqyXlRrV+f9hg/hE8KywB9vbUwWYvHizRqUISTbnF03UMZk6oqPq8yEprdY1wGb4gBj2BBtv10QRiGh5nP1RE6QHPqObSmi7RazFsxs68Hvubn9qrRm/+h6FryKg6tdJfS1LwY36eprLpwtmmcSIqIaEC8AVE0bzX4ylRqOYErq63imT7UZnSpvuSva7yT4kiov2Z78CL4cjo+AgtTMGf 7OK35CrP 1o4AmE2JtEpUVimq3EQ5Iu6QS0I8+MaFY74j8u4fdzEdYLMcB0brL3jQ2sCVojKiyteWbA0x7GTrhAvspi9DahAlct58YkNRxarpx3wXR1Kvxt9XmEiautesYJK7YNOUm03LkOiFpuE/vbi29eYbsi1dTfaUPjl08hKm5WKkXN81VecIxcOmW/daam7AzVnCQvc44XNpY6lGBUVf1qcBq7CZGRMIfPoahYQ/CyPVfcLJD3ZqID2Bcd9t6yi9lCu7FUy3fZ3yOuOIrCOpwL4yUu7NiGXCLNZamuDyJxBQ0IuOUG/T8eqsGcp2LDo0PNWjif+lABwKGvTiclrZH0lPTOOke2aH0lwvdkd199AqySbf3V92tk+HlTmzkLCrPLjGNSAwbyus4ucjsbH5orV1xQ6SoBJt+8RIdhjYALIjPZUMACqh0GmS3mUCIXVm6aI0z2aunrwUi4r/W5hy1Oot9mohroh5BYqY4pHdBC5h1e5t4bJpElRKtpwTt48pn+CAkmoOpChZfISI6xWjGdLNkypyWqxXq8IWknTUStNavP8B6iJ0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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? 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. Currently we only do that for debugging code, not the code that will be used in production kernel yet. Cheers, Longman