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 0A63FE77187 for ; Wed, 18 Dec 2024 08:38:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6863D6B0085; Wed, 18 Dec 2024 03:38:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 60F256B0088; Wed, 18 Dec 2024 03:38:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 489036B0089; Wed, 18 Dec 2024 03:38:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2B4DF6B0085 for ; Wed, 18 Dec 2024 03:38:23 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B2043AFAE5 for ; Wed, 18 Dec 2024 08:38:22 +0000 (UTC) X-FDA: 82907426826.25.15786D0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 53BB040003 for ; Wed, 18 Dec 2024 08:37:34 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XK6gYthq; spf=pass (imf07.hostedemail.com: domain of acarmina@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=acarmina@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=1734511085; 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=LXhZeUFK6b+cNEJmj0OqH76u6rSs98YqB0iwpOfkRQA=; b=ybaJ85HPIfphnUwZFXWkl1Bbc+8xvIOxt4gF1trgxOc/9rz1GpMYxB3mgtoDBJalQDw5Oa GK5vaQTuMaN1Pi+4FH7CbsuFFGtg4lNFcqmToI5qTOts3XQaz+cmY+VH3xH7zCfxqGfFqs Ook6p2LtLQbwUtHUMpSihMBTZGzONmQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734511085; a=rsa-sha256; cv=none; b=YTpCy+lD2RVz+xlrkepi7JPUWfihymo6NQunr1PA/ndd2KP5wggDTC4jRnZ8l9DaubYkLw KS7xfj8QzgoRi+VllFMSRIy8BChC94tDFpbwKIQtOVju55yYDrzTq/IvQN3tx++CaIQ762 cWH0400gcsJqrvBaCLN8eaywFJdkyNk= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XK6gYthq; spf=pass (imf07.hostedemail.com: domain of acarmina@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=acarmina@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=1734511099; 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=LXhZeUFK6b+cNEJmj0OqH76u6rSs98YqB0iwpOfkRQA=; b=XK6gYthqAJkzVKCIrMY2jbTMUkkgWoFrKlIIwCoQoE5JJ19KfMDAlBYCbaS+Goo1eesC5L O79xySt6icL64FgAaPG+DNNnQD2aHQWSSY8wz/spnt6rtTNXtBGaeped3s40+W3FK/0PQv nmBfyjwDr5lvW2RtIyGq008DjBIrRhA= Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-257-KrHvC1_JOyel-rizIBAg7Q-1; Wed, 18 Dec 2024 03:38:18 -0500 X-MC-Unique: KrHvC1_JOyel-rizIBAg7Q-1 X-Mimecast-MFC-AGG-ID: KrHvC1_JOyel-rizIBAg7Q Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-2ef6ef9ba3fso5889967a91.2 for ; Wed, 18 Dec 2024 00:38:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734511097; x=1735115897; h=content-transfer-encoding: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=LXhZeUFK6b+cNEJmj0OqH76u6rSs98YqB0iwpOfkRQA=; b=c/grpcDqU8ci/IirrUrBmuZIqYQhI3K6rDxqUC3Zp7Mue2z/t2JiymZoTvEWhbDH0R t4liza78hQC4wkPo73HciRH1CJJ6/YF464vKBmJymh0l0EOXjbg5V0ZpyQ5kHugpSOVH dQrAInO1y15l4+PM16ajhN5rdHpW8Ud+UVRg3R1LW4/CSE8Vz79xGWoNQZi1x/dxDml+ dgvMQBk+IKnz+ZEtwhMpeQcsIfOzhow/2Med0n4xuC8qMdV8sL+DznCTD5goq1n0wwRq WYUP1D/1+osrG58H6MxCIvBAW2dOgAWHCtyBl26HGcYBOdFvGA0f3kqzxgEgEqVLxurR eZtw== X-Forwarded-Encrypted: i=1; AJvYcCXFXiuoHUeyUvuIwDtzf8+krhiUCgxEHrVhIlzNJf0/e1UnnsrpAoJenNnj2pq5TsT6d7kTyOupzA==@kvack.org X-Gm-Message-State: AOJu0YwAR8sRiq+gl28FEnE4/Ar3PTtrvuv4DyFfTQasuiUnCLfVdci5 qj7YQh1DSKrJ9EjMu3p3oL5Juq9e4Y8R/jhkvEZ1FVkOg3Nj6/0PxIliEqfHKXWj56nd4zp/M1+ BVye0FsAUzSERJHb1N1hoiHAY2Az9mWhMpjyGwPRYa8eSqvq9mF2WHb7QiMDJaaGae3wnuzgMGV +cfgRrVE1oBO6QIWzYzg65eo0= X-Gm-Gg: ASbGnctxxweTGOgaxtuz/Z0mK2Umh26gOK6j98Ni9z5C1GfahHM/AUjsmVaR6lmTR+J LbC+ZWI/01dsgNjAI3RK/xTIIs5nmNrre7u41 X-Received: by 2002:a17:90a:d88c:b0:2ee:b6c5:1def with SMTP id 98e67ed59e1d1-2f2e91a9f37mr3013716a91.8.1734511097568; Wed, 18 Dec 2024 00:38:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IERJ+rCyFaCK9KWdPjeSfugeNQbClj+M3YtT1FmXeAPS6uU9onXzRO23fVdJD39RhVX7aosUaYaDbwRn9x+h8M= X-Received: by 2002:a17:90a:d88c:b0:2ee:b6c5:1def with SMTP id 98e67ed59e1d1-2f2e91a9f37mr3013687a91.8.1734511097206; Wed, 18 Dec 2024 00:38:17 -0800 (PST) MIME-Version: 1.0 References: <20241217142032.55793-1-acarmina@redhat.com> <20241217095504.ea2a3a24564af4df48cf0b19@linux-foundation.org> In-Reply-To: <20241217095504.ea2a3a24564af4df48cf0b19@linux-foundation.org> From: Alessandro Carminati Date: Wed, 18 Dec 2024 09:38:05 +0100 Message-ID: Subject: Re: [PATCH v2] mm/kmemleak: Fix sleeping function called from invalid context at print message To: Andrew Morton Cc: Catalin Marinas , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, Alessandro Carminati , Thomas Weissschuh , Juri Lelli , Gabriele Paoloni , Eric Chanudet , clement.leger@bootlin.com X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 5t2AyWzdhpiVgp6Sjye8EEM1dONjfC-WYfaAYSzGkDU_1734511098 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 53BB040003 X-Stat-Signature: mdt1pfytep8s6aofc1xmb3a64c3e7a3j X-Rspam-User: X-HE-Tag: 1734511054-93757 X-HE-Meta: U2FsdGVkX19UltWFCDIHYN/bYINNP2tJpS0Tdxhh536VGuicSj9Yh6u7wZLkm55Fagg0Ne3kHYZN7gz60X9rMcP4jid+hLCF9FfrcCkui8I1TQNs308zW0WWBuMj42y4lJ1ZP0977Z9pQxIdvFyK+nuqf9hEr9bRFerFv5urLRpBSRnZ3jmSRPKZ6k+jnfXJuBexcte6HdG4p6moZkPrs6OHBV+5Mhs1+nfSmJIKT6GPwN9mLsUvv+nimh/BtfdxON1lZStXR1pGDH1KC7UVmYJ5IK29QnkhIyF0wpg5u6LObdaUqSdmeG7iXbzW4uexHdFb3Zm55mJnoVka+dPuVadQ9KP8ETCy6us0wyYxZzlYweFUSeGQ8UOMMRhkP+yaGwv8mnJCzxz7d0DaJGL4CJNOzAUW1kOJSQVjmnLnAbgsDD7p9Nbzxu3qZhSVFgvUOBVvJMXyJYGHiZcFbxgMAnnIK4Xu6HjiOWW0sYGWQ5byxzLb3W9/Lh6z5m010jOuQUIHgOlkRhJo/1UlN7O7rtGTUkAYHcAjdfs5QD3Kt8IcnZXq4XrrtA4kopEDjabmLaQV+agtWoipyZe3cPtwunhGvVMlXlXakJWfcOaviwX215nCTMD6SbQIZit4FxFmEvuwIRTtapGObKyiVqKTecIrjdgTjsM9jbTAweXfj+Gnul//u6O6OHhmM3e1aktByAombXB17idJx3BROsySQSt3uYp3HI3dLB3DeViGDc+kDZHIy2dFZKqR7bDYPyIpAmdr/ksE76zbGceGpfH+NWCNPS7WrZm3nOK1wqIg9D/IkcalIY5pHO6V6R2sANAPAtq2y+URSoXMGKH+CdHC5rEJb6NpLerfwdPYAyAAql5hkFGGh1VgEtDMg/OLbUPO7g+Hm9EeF25BIL+Qw6W/R8ZzvWslG+d/vcrkvDnUWzLuwJ2mfOokxhKFUjuj+aZbDWhL1ORdsHXbgWuTnoY F/SaRLn2 Dfzyz1Wynfn8zieyFQ2xL5cip1qmQ5ShdPE2KOi87GNyXwvbXhFHi5aFGxU5SEkXVcvme/PhKrZYk3uQG6dw/SWWAaLhq0MhCSthPhot+vyjoLE0y6FZJ4EmNbgw02XzW+CTgJ6lzOcLxZOUw1lCgjtUPFdirkRUlq/mLUOg70EY89doeZV7TCbV5nj90WckvK0Mn3VzOXXkNnGj0kfgWbh/8vw2elJcwPWuKJ+dumyHGGz3K+vognKslNkdsTrWYi52Rzs5o6g5V/1SCB8hJoUGUt6JZcP9qt84FTq6zNpCTFTuGbrvJ0dC0oC9tuucNtzCvQVWnIOzHz5gYMXljVdFG4wvgdeUAyRR1bRZLWitaQPkzp+SIbyZVMyg+/UQiQhM2NpCU9DH7lEP2H42XZTFCPi4cpole+4iyJoCO5RQjeMQ= 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: Hello Andrew, Thanks for the feedback. On Tue, Dec 17, 2024 at 6:55=E2=80=AFPM Andrew Morton wrote: > > On Tue, 17 Dec 2024 14:20:33 +0000 Alessandro Carminati wrote: > > > Address a bug in the kernel that triggers a "sleeping function called f= rom > > invalid context" warning when /sys/kernel/debug/kmemleak is printed und= er > > specific conditions: > > - CONFIG_PREEMPT_RT=3Dy > > - Set SELinux as the LSM for the system > > - Set kptr_restrict to 1 > > - kmemleak buffer contains at least one item > > > > BUG: sleeping function called from invalid context at kernel/locking/sp= inlock_rt.c:48 > > in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 136, name: cat > > -rt is a bit annoying this way. Things which we expect to work OK are > no longer doing so. > > > preempt_count: 1, expected: 0 > > RCU nest depth: 2, expected: 2 > > 6 locks held by cat/136: > > #0: ffff32e64bcbf950 (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0xb8/0x= e30 > > #1: ffffafe6aaa9dea0 (scan_mutex){+.+.}-{3:3}, at: kmemleak_seq_start+= 0x34/0x128 > > #3: ffff32e6546b1cd0 (&object->lock){....}-{2:2}, at: kmemleak_seq_sho= w+0x3c/0x1e0 > > #4: ffffafe6aa8d8560 (rcu_read_lock){....}-{1:2}, at: has_ns_capabilit= y_noaudit+0x8/0x1b0 > > #5: ffffafe6aabbc0f8 (notif_lock){+.+.}-{2:2}, at: avc_compute_av+0xc4= /0x3d0 > > irq event stamp: 136660 > > hardirqs last enabled at (136659): [] _raw_spin_unlo= ck_irqrestore+0xa8/0xd8 > > hardirqs last disabled at (136660): [] _raw_spin_lock= _irqsave+0x8c/0xb0 > > softirqs last enabled at (0): [] copy_process+0x11d8= /0x3df8 > > softirqs last disabled at (0): [<0000000000000000>] 0x0 > > Preemption disabled at: > > [] kmemleak_seq_show+0x3c/0x1e0 > > CPU: 1 UID: 0 PID: 136 Comm: cat Tainted: G E 6.11.0-rt= 7+ #34 > > Tainted: [E]=3DUNSIGNED_MODULE > > Hardware name: linux,dummy-virt (DT) > > Call trace: > > dump_backtrace+0xa0/0x128 > > show_stack+0x1c/0x30 > > dump_stack_lvl+0xe8/0x198 > > dump_stack+0x18/0x20 > > rt_spin_lock+0x8c/0x1a8 > > avc_perm_nonode+0xa0/0x150 > > cred_has_capability.isra.0+0x118/0x218 > > selinux_capable+0x50/0x80 > > security_capable+0x7c/0xd0 > > has_ns_capability_noaudit+0x94/0x1b0 > > has_capability_noaudit+0x20/0x30 > > restricted_pointer+0x21c/0x4b0 > > pointer+0x298/0x760 > > vsnprintf+0x330/0xf70 > > seq_printf+0x178/0x218 > > print_unreferenced+0x1a4/0x2d0 > > kmemleak_seq_show+0xd0/0x1e0 > > seq_read_iter+0x354/0xe30 > > seq_read+0x250/0x378 > > full_proxy_read+0xd8/0x148 > > vfs_read+0x190/0x918 > > ksys_read+0xf0/0x1e0 > > __arm64_sys_read+0x70/0xa8 > > invoke_syscall.constprop.0+0xd4/0x1d8 > > el0_svc+0x50/0x158 > > el0t_64_sync+0x17c/0x180 > > > > %pS and %pK, in the same back trace line, are redundant, and %pS can vo= id > > %pK service in certain contexts. > > > > %pS alone already provides the necessary information, and if it cannot > > resolve the symbol, it falls back to printing the raw address voiding > > the original intent behind the %pK. > > > > Additionally, %pK requires a privilege check CAP_SYSLOG enforced throug= h > > the LSM, which can trigger a "sleeping function called from invalid > > context" warning under RT_PREEMPT kernels when the check occurs in an > > atomic context. This issue may also affect other LSMs. > > > > This change avoids the unnecessary privilege check and resolves the > > sleeping function warning without any loss of information. > > > > Signed-off-by: Alessandro Carminati > > I'm adding > > Fixes: 3a6f33d86baa ("mm/kmemleak: use %pK to display kernel pointers in = backtrace") > Cc: > > > --- a/mm/kmemleak.c > > +++ b/mm/kmemleak.c > > @@ -373,7 +373,7 @@ static void print_unreferenced(struct seq_file *seq= , > > > > for (i =3D 0; i < nr_entries; i++) { > > void *ptr =3D (void *)entries[i]; > > - warn_or_seq_printf(seq, " [<%pK>] %pS\n", ptr, ptr); > > + warn_or_seq_printf(seq, " %pS\n", ptr); > > } > > } > > Before 3a6f33d86baa we were still printing the address, with plain old > %p. Should we restore that, or is %p always useless? > The intent of 3a6f33d86baa8 is to make pointers available for debugging purposes. My argument for this change is that %pS provides already sufficient information for debugging purposes. We essentially have two scenarios concerning %pS: 1. When the symbol can be resolved by kallsyms: In this case, a symbol+offset style pointer is emitted, which I find more useful than just the address. 2. When the symbol cannot be resolved by kallsyms: Here, the raw pointer is emitted. This undermines the original intent of %pK, as both the masked address and the plain address are exposed. If we want to be picky, there's an additional factor to consider: KASLR. %pS emits its output accounting for randomization, but in most cases, the randomized offset information is lost. The exception is when the symbol cannot be resolved by kallsyms, though this should be rare. It's still worth mentioning. Back to your question: %p emits an hashed address that is not reversible by design. Therefore, in my opinion, it is not particularly useful in a debug message. --=20 --- 172