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 38788D78799 for ; Thu, 21 Nov 2024 17:04:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A30D26B007B; Thu, 21 Nov 2024 12:04:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B9726B0082; Thu, 21 Nov 2024 12:04:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 833836B0085; Thu, 21 Nov 2024 12:04:10 -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 656806B007B for ; Thu, 21 Nov 2024 12:04:10 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E3BA41C75A1 for ; Thu, 21 Nov 2024 17:04:09 +0000 (UTC) X-FDA: 82810724556.14.4DD957B Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf18.hostedemail.com (Postfix) with ESMTP id BF6951C004C for ; Thu, 21 Nov 2024 17:03:36 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=AnJAzri0; dkim=pass header.d=linutronix.de header.s=2020e header.b=ebDQDwM8; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf18.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732208573; a=rsa-sha256; cv=none; b=1ommAgACG+nTvMYr0xz12A1K/uUdyjAdH6abaT7fH0pLP9JkmvtcP9b6bMrWK6RerzHZze FgspvaijlobL1pI4hgdfYuR8TLslD+OlFmx+XLU25ADPK3aG3ah5ILEygourIH1skU3WMY HghJJ4DSldfSGGW69nqVbv6bzsP6+3E= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=AnJAzri0; dkim=pass header.d=linutronix.de header.s=2020e header.b=ebDQDwM8; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf18.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732208573; 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=gsVeeDT0PE0eLhTaYmgb/vHP3YXOVl/p460fTYStwy4=; b=sNC15MXu2lSpM05cYqtbIeN7pOsDFohAGdgB++twOXkBN8fN9zQ0yEpDO8IzkASCY1nxCo U8VfDCTYvvZSoYnKgEDnC0YBB/OrAAVz8jp1gi/CQP7oGm2NL+jwCr3gDs/d+kaa59WVq/ fAh9OTTLaat8/XvM84zgq4rWahisNKw= Date: Thu, 21 Nov 2024 18:03:56 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1732208638; 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=gsVeeDT0PE0eLhTaYmgb/vHP3YXOVl/p460fTYStwy4=; b=AnJAzri0dx9qoeJHBwWB3tOmHcOe0a4hrBItD55XDsCGfsMjAjYg5GziTQY9h//24SyAjE 9b+wZXaRVbloBS0ubd01Ard7XJJwnxLoz0CULwMCZpFCfV7MXBCkI7YMASYI//uvr5uJEd xUlqs2jhjALy2jODR7he1RTCRslCZR5pwmsDQTAGg3mWd+SRglMx8/Ow6lyTA0xg4InUkr oUjAa+xEydfy/IzhwQiVs59736uP2GfcmKOpO6WFzjJeDMY+76UM3lghpYyrhR8oXQOQ62 QyHESm3Lxlx2GLLjHlp7RdRwH5HBn28FpC8iagliNyrNqEkJL3uC1JukuDGhhg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1732208638; 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=gsVeeDT0PE0eLhTaYmgb/vHP3YXOVl/p460fTYStwy4=; b=ebDQDwM8tFsWvVfHSNy3P3COE0Vq8ZUoQfcFZJ9WbWJi1Hca90syqjqTdaYVb/kvUHWksV uZezUUWqJm0XGsBg== From: Sebastian Andrzej Siewior To: Alessandro Carminati Cc: Steven Rostedt , Catalin Marinas , Andrew Morton , Clark Williams , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, Thomas Weissschuh , Alessandro Carminati , Juri Lelli , Gabriele Paoloni , Eric Chanudet Subject: Re: [PATCH] mm/kmemleak: Fix sleeping function called from invalid context in kmemleak_seq_show Message-ID: <20241121170356.eC7f3-1v@linutronix.de> References: <20241120102325.3538-1-acarmina@redhat.com> <20241120102602.3e17f2d5@gandalf.local.home> <20241120164043.T1JuBALe@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: BF6951C004C X-Rspamd-Server: rspam11 X-Stat-Signature: 66oaxbu5ytknckjj73r3tai9wp7tdsqh X-HE-Tag: 1732208616-617861 X-HE-Meta: U2FsdGVkX1+jKziGWvIexgBjwQa3DsKjselAetvaeBrS/GKruDjJedzOQKejyvYhMTqRI/Ma8/IutTLaE/0XWKK0G2kkp+D0BYENtew8WfynLk9IO0tZ0orShQmriY/UANBfeknPJbdJqeSFgi8tzAbW6SZvH3OMqYHWplf5UdHERmhJz3VvGGnKCsvBvaKle1e/nUVMemTq5MJ36vtWu0ctg41bLqyOu2DwgZbi0wEd6/FQ7S2bGvE4pFOPpP5z67PVgsrumgQNrhVF6KsdW1QBmkC4YJXhCjIIORNnc4AASsZtzwKg26n1JsmrSPtyLpxnyAPI1KKu/C7Sc85cOLhFxCL82s3wTJS1SjAxTeMFYT97LaZHH5H8wm70A4otwVA+qDJx2I5ISDmwCIwszZnwbF15NxkurQhqgcSHRz9BdYI6jAIUvYepqtXhdv09chnTnEiDt8CmYPcF3MT3gXj6okMn5zq1rvbsE4WiY+1BAvXs/O/IYgOjmWwNZ2xxqJkC8f8DmQNziSRxkoJHyelh130LPW6UB158mflE0SOMbAnD3g+uJjpMJwIbctdmVP0uvK8R/utAqfM2GjfqmPNzKT00oMQD/L5721x/uCs5JnC11OX9YdTHy45q/SHdtW1GRtLkqI8RABCrPJZ1SvYc4MP2sM3bAHOzmtRm+lMqhQXBByEJlRxOoQ2XPod/kSljQJN2ClvbW2n+/npHq5RZ2IYJdJZk+t6qXb130gSRYmgWsC9j/Eew1aqpvqCUmHrS7Rk+zRccErnaONJ/NtyU1Ch23yVW8IbfszJejXPR7Y1laYeMSzzx88kxqO5J4Q5yq0seXFppWRUintPmph02VybzPi9J1zWTOciQuwYMSC5NSBeiStMw5VKk8Tzfoetuspvo21A+H5sGiLijOEVmdL2icA72RDGMcFM0rnLtFr+ZPVzQffLcpsDOofAMTzYa/+QL7JlfjSdYy0z F+nU6CS+ fwfuIba9iEVO3x593NMHZ23emmL5tPCoL3UYMt0RAQi3YqOBM936lTKUSWjnKL5nXWKijaDwItnbsL1gJu0x97K1qwkodTMcM0jM8HCNnaIGEs5x6efY5YFCumk7nNSHYtemth3Kz+YRyhc96o4+vx8+uIzsb9mygd4Yd4Ab8qw/fn+trPnp6hylCbO2160GETmMNUb/q9ddt+sITHYMLY4nJPdqLnJ8Bp19rWXQSR1CYDHDJabqnX0OznJlFwYpQ7HPkhXR+a7y5pZave1D4bqg7EQ== 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 2024-11-21 17:50:06 [+0100], Alessandro Carminati wrote: > Hello Sebastian, Hi Alessandro, > On Wed, Nov 20, 2024 at 5:40=E2=80=AFPM Sebastian Andrzej Siewior > wrote: > > > > On 2024-11-20 10:26:02 [-0500], Steven Rostedt wrote: > > > The "%pK" dereferences a pointer and there's some SELinux hooks attac= hed to > > > that code. The problem is that the SELinux hooks take spinlocks. This= would > > > not have been an issue if it wasn't for that "%pK" in the format. > > > > That is missing check and I think Thomas Weissschuh wanted to add it. So > > we don't call into selinux. >=20 > Your comment confuses me a bit, as I'm unsure what Thomas is actually > working on. > Am I correct in assuming he's addressing a fix in lib/vsprintf.c to ensure > that sleeping functions aren't called, allowing these functions to work in > any context? restricted_pointer() has a check for in_hardirq() among others. This needs an additional PREEMPT_RT check. I would be actual in favour to get rid of case 1 for kptr_restrict and have either 0 or 2. > However, his mention of "This fix for kmemleak is still needed as the > pointers in the kmemleak report are useful" adds to my confusion. > Meanwhile, Steven suggests reworking SELinux to resolve the issue. > Could you clarify what you mean by "So we don't call into selinux"? This getting out of hand. By adding the PREEMPT_RT check to restricted_pointer() we don't call in selinux so the problem is gone. kmemleak is not the only problem. printk(), as another of vspritf pointer code user, can be called from any place and would also trigger a warning here. As far as "kmemleak need to be usefull" goes: With kptr_restrict =3D=3D 0 then with or without pointer hashing they will be useful. If we need to go via selinux then it ends as a hint. Sebastian