From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08C882D7DDD for ; Wed, 27 May 2026 15:45:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779896732; cv=none; b=nwZEferj1X6hjXxZT6GlYqodDYLm0HZDJ5JM0Xi86iOtW31urFhWqtpSoIlitO64AiYU9aN15pwCZ6+ac0zCEpGHf5xd4C5FEUjxrP3LH4EhgFlOV5ioorSBQGA/WEiL56sMumpn3QJX2cr2NlFEOZZzUL4zI5OkW8cJQ0sCn0E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779896732; c=relaxed/simple; bh=MmHt+UFOdVwRwdDF9g5bD5yVltg4QmEY1TCRMiU+UGM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CqDuU22jB39+APT9rI9Lt3/h1vetBLV6r+1yNNJZ8cs9FlIKK+fEiMhQOLkumnjlu6+euov4n4t5fImXLQZAPRBh6JOwytYTWD8WbgCvfa0kbhKA2BBny2+XpPf4E8pGAxd5/NQ+COI0BmqtBYrTuxef+lksxDUmhZLgxhXl9jY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=bOczF1P7; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="bOczF1P7" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4891c0620bcso75911435e9.1 for ; Wed, 27 May 2026 08:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1779896729; x=1780501529; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Zv7j3mYs+kArFa1PD+NhbMjrh+f1ty1pTSvGqulUIwI=; b=bOczF1P76NL2/4MPEQnesgU3BZ2lDClMp/UCeiJw+C7bZr+E9MqvVneP9IGryxi+mR eisJGSWc8OSQLs1PbjkvdBcATFkOiycEQoZS+S7YNGyx2uboM23e+yFKVge6KXvaT5mg T/AUcGLXbHCNhxrgC5x5H6POOlrB2aqWTwoYphkJ46gsanIqVlRXInj3gSl9hCtQ56zx dQYTrpGDo8fwTwUYOc5poY6LnTPJNn+L9YMVxLC7jTZ0YoJrQNYIhiuG2ndvQp/j+eHL yyMsso6o3WTEfzPmkIp+VoskosLha5p2j1sAfhzN6/cNo1YOUTl4ypi9BLxc+AzmaKU/ mujQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779896729; x=1780501529; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Zv7j3mYs+kArFa1PD+NhbMjrh+f1ty1pTSvGqulUIwI=; b=OEQyoEkK8/FZeec+vHvhTH+SZa5DPbAzI7tGLkutvm6C7XPFrPJQxF5Zh+x05srgsz Y4xWiLMZTHZuiWlhX6q1MCziQFkTC0zTHuuH3OFUG1dio3V/H0RpFo+uxk1BoyuHjg3P w7yawMqas/k1uNFRPoRnaWffKHXVab5GrnuQEXxW82H7TVh2BPATNWZRmmK32SwbW8Du kSumpiQvAxc8EiC2qrg1firutTu6jMv0MwcsG+6Wa7MDY1E3sXWiWMeeD4UQrU0lnXz1 bDAgoZPKrY8q4J5VU2TU7wpxhzmbh9FugysBpsqeKtiRM9mtiaUv+Gq5Fd1+ZkNnN1Yt qpRw== X-Forwarded-Encrypted: i=1; AFNElJ83iHzPXHUVasaiEUNFVoJl0wIwm1PdfiJu1GD5B9Te3/ePBzUx5IZd2MjM+io4E7lKocbQvHcgHikYq8M=@vger.kernel.org X-Gm-Message-State: AOJu0YxyvdgHN+uhssMA0lA/+3QGjdU5hk8kY+h7ROZ6q4mEJOwZRt1o faqAFZ4a8MvuVv1tABQMvpj7gk/Hyzv/BWMTeXRTZfSB/giqHfiHEJuoSEtk+bVPqOc= X-Gm-Gg: Acq92OGN/DbOI8Z491LUiis6nKEPn3HiHfa2YNqCgu6q71gspOU5yZnm/HDaYzKg6ZB Q2XTzKjnRvfbQvtzWHD8NqUfublblZmg80mhFz7atNR8eKauGIW4SSSpokKdA1LQIwZbJDa0Dgn Eo1y/y8S/6Ek8tVMDCeZW5hYW1B8UlOFeKeyE0lZgolkw8pKUbcuKfAmEuBH34s7qnQ2js3FD2o vnXsDbw8xus46LMPPc/0bZUOTmIPEeJxoiXyAJpgVU3oGeR7C3b252G4MN+L1mb3LoBsjR1rpPJ 69QOrQ2d/+vnL3yLbcBo9rAAootuZQ4HaJaBeZhUsnfxWmz9xAy2VpGwd1N8GUpCzUvTJz6NywR hV0PAqQdrfCe09wYBo6jhW37ISUTCFFxSCzvk4ohCBj1bgxg/OHSZ0baQ38CLsuN0B2M8XSsARi 56d1c0U6Gnyq3HBaQNKNJPfhkzeLzMrZ9wu7PRKq5N X-Received: by 2002:a05:600c:64c9:b0:490:53d3:47a9 with SMTP id 5b1f17b1804b1-49053d34b35mr328797395e9.3.1779896729353; Wed, 27 May 2026 08:45:29 -0700 (PDT) Received: from pathway.suse.cz (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490452765f5sm420980525e9.5.2026.05.27.08.45.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2026 08:45:28 -0700 (PDT) Date: Wed, 27 May 2026 17:45:27 +0200 From: Petr Mladek To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Andrew Morton , Steven Rostedt , Andy Shevchenko , Rasmus Villemoes , Sergey Senozhatsky , Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Waiman Long , Sebastian Andrzej Siewior , Clark Williams , Kees Cook , linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev Subject: Re: [PATCH v3 5/5] lib/vsprintf: Always check interrupt context restrictions Message-ID: References: <20260520-restricted-pointers-final-v3-0-76bca6a6ab3f@linutronix.de> <20260520-restricted-pointers-final-v3-5-76bca6a6ab3f@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260520-restricted-pointers-final-v3-5-76bca6a6ab3f@linutronix.de> On Wed 2026-05-20 10:40:04, Thomas Weißschuh wrote: > When kptr_restrict is set to '1' restricted pointers can not be used > in IRQ context. As kptr_restrict can change at any time at runtime, > this means that restricted pointers can not be used from IRQ context > in general. > > Add some assertions to detect misuse early, independently of the > runtime configuration of the test system. > > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -871,6 +871,8 @@ char *restricted_pointer(char *buf, char *end, const void *ptr, > > guard(lock_map_acquire)(&vsprintf_restricted_pointer_map); > > + lockdep_assert(in_task()); It might make sense to do this assert before checking the fake spinlock. The task context is more restrictive than then the spin lock context so we might want to check it first. It might prevent confusing reports about inconsitent IRQ usage. This function should not be called in IRQ context at all. Otherwise, it looks good to me. Best Regards, Petr > + > switch (kptr_restrict) { > case 0: > /* Handle as %p, hash and do _not_ leak addresses. */