From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 98BC63FDBE8 for ; Mon, 29 Jun 2026 12:06:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782734784; cv=none; b=r03kUPSAGTjyeYeMek+lyXh4E1cWYFxlibN6ZHGCkPPFbi+d6nCgQnjb+qvytDdtobM9xunEHfOeeQWfgJCvzNOt2w9ClRWCHjm5DUeqWbMzJsqwFIz/wWAf3I6Z6hbOB7Gg+KSrAm5EBoUDBfSqA9fGoYX0fKM2sBtFcdzEpAI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782734784; c=relaxed/simple; bh=s1Zt1nkU6AtVgXZaEG/G39e4v4/ThPUcVNXHxkYXdbI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ha6VqdA8JgOY0mkd5H+7JXsZI6A+gdb8XunX9uB6FTCssUBeRPX7pTdGQy+h/9Qu3Hve6ijROw9CdOSsNdpQDuYrqcMiD2MopaCuVM/7M0ktga3XAhiNQERTDrnhlGTnuEL1Mv48ShShG0Tisk2YvVgXr5W2hZPStld7121WAmk= 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=f3O833sM; arc=none smtp.client-ip=209.85.128.49 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="f3O833sM" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-493b29be0d6so5994335e9.0 for ; Mon, 29 Jun 2026 05:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1782734781; x=1783339581; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hpoE++Dc53tmLwgNaoaxx1b8EdGUPsK36vhuvC33KIA=; b=f3O833sMriBWxhRfftilQDMRenDn600OPm5VcjPQC7tH3cN4biSnf8ytdKh0KjdmrT IurGKQWQChnQrzcZT4pNkWlnPXQr6phtbgvHaq4y5Y2zzU2hNGzD6JxzfiJ4m/8zl5cp 2O9VePu+Drg+jmY3sbMve2xDKFg9pNP6XaSKatTK9lHqUgqolr0Vfp6zl4dgxM7gZ+iH exjdwBIfoobfpTlFd3HsnT4DTsXTlDEnRuJN3+DjPqPpRWaL9zxTZGX1amVbkHN3/lSS TWPTWfOFUrIWfiWZqNs2KK5O1kVObk1WTPSvRgJTkhXP5IFLelFmIa60iBw6tJPTxhXp fzvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782734781; x=1783339581; h=in-reply-to: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=hpoE++Dc53tmLwgNaoaxx1b8EdGUPsK36vhuvC33KIA=; b=S6oO2NiTU97DgGshBINqSq55WemYIMYmYKg6NN0ipMMsMZYygBDcS7Qax3o+9BEkRw 3guZ1RRnRKkfC+wxW3wfK/F5Mk567IkjlELi+CVqTzd7WOKDvn+oM6ck6WraLnX9Pq2W z8QWScz9j5cT5CnsSAOlofSISCh84llh5iEtdjbFBhsuJG2kCfK0flpU2dI+9qhdj80b lrn+JRP1CwVLGDpOVY5FDE9ghCmFvmx9QxruoPBPeTxHcUCadEbyIVzjMfagIrrA2FRy 4WpvHThVHUT8tR0UGVDXnI+XQwpzQlNTbaLRXoqP10myHgUIGepL/g+EGgQMze+Dddvs RzYA== X-Forwarded-Encrypted: i=1; AFNElJ/GXKSLpNDC1woPcTuIM1+/bXdoTjgZM4e6YIcPAWwZ6lw2CdE4MvNAjCm+yhXeo4IgEma61euoC2lfR3o=@vger.kernel.org X-Gm-Message-State: AOJu0YyvVO8AMGXb8vGVFSylniqQjHBielUMAfW6wXzC4m0l15LxCsVy bF9vIMZZhv5js3EAdv3+Wn+Wk81grtO8/XiBJsf+LMyTXMGtyMtbW1scitsiFJu1vdQ= X-Gm-Gg: AfdE7clD5UBwYAqhfNenvhAIHqhWliqXm5JZdYAodYpJ3P3iMX1nhVGCnbAIGyECaii qfYeENKxFqZZ+7BExxKjPokk2nmgUwi3xLMNomaYk2A1p1NsA9NbKOMqOtzObJ4RG9d3q4wZeUB gpY+6One/sbHpe2lWz1YvISV2+SgBpqEu8brMaPCWkeNkkdD5egu6IeLT8n3bvEJqxzXjg8F1b+ DlRDJW1HlrksHXGcOnRtXDzSxER1wnW8SrxBHhBgoMhINiXLvb1CTTgNFU1rnOLKalb3evwmuY7 ThcjgpDsFV/+uTlGYsfob9dxg5ERbA0pA/mz1dn10g0S9Z/jRoYl8Us2nx0iRY577Kr3LbGJav7 QYwPV5TFYmzr5I0QVeLQosI7ek/XiL60AnmzYBZjxMEFkOD4rogWHrS6GjY73i1u3c4TuoLMpCj 898gEcVQU2vk6bEso= X-Received: by 2002:a05:600c:c493:b0:490:e180:2e0 with SMTP id 5b1f17b1804b1-492663d6dbamr216363955e9.3.1782734780897; Mon, 29 Jun 2026 05:06:20 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49268ff9f40sm286395495e9.6.2026.06.29.05.06.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2026 05:06:19 -0700 (PDT) Date: Mon, 29 Jun 2026 14:06:17 +0200 From: Petr Mladek To: Sebastian Andrzej Siewior Cc: Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Andrew Morton , Steven Rostedt , Andy Shevchenko , Rasmus Villemoes , Sergey Senozhatsky , Peter Zijlstra , Ingo Molnar , Will Deacon , Boqun Feng , Waiman Long , Clark Williams , Kees Cook , linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev Subject: Re: [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting Message-ID: References: <20260608-restricted-pointers-final-v4-0-9a436615799e@linutronix.de> <20260608-restricted-pointers-final-v4-5-9a436615799e@linutronix.de> <20260611120615-4252b75d-55aa-4bed-b64b-0316b2148d2c@linutronix.de> <20260625145115.KZ9l1-lv@linutronix.de> <20260626170658.0bqzsB-1@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=us-ascii Content-Disposition: inline In-Reply-To: <20260626170658.0bqzsB-1@linutronix.de> On Fri 2026-06-26 19:06:58, Sebastian Andrzej Siewior wrote: > On 2026-06-26 18:06:09 [+0200], Petr Mladek wrote: > > > Interesting, does the spin_lock_irqsave() even allow sleeping under RT? > > > > > > I mean, does spin_lock_irqsave() violate the raw_spin_lock > > > vs. spin_lock nesting rules? > > > > Ignore the silly question, please. Sure, even spin_lock_irqsafe() > > is a sleeping lock in RT. > > > > That said, I am not sure how to effectively pretend the right > > context to lockdep. It looks a bit ugly to disable interrupts > > around all the code which is guarded only by a fake lock_map. > > That splat is from !RT and here it wouldn't happen if interrupts were > disabled. > On RT that interrupt (softirq) would not interrupt as such. So it is not > possible due to how softirqs are processed. > > My idea is to remove that thing so we don't have to annotate it. > The reason behind it: There is no added benefit from my point of view. > I can't think of reason to return real kernel pointers via proc/ sysfs > to the user which depend on a security policy. The %p will return a > value which can be compared against other values and check if it is the > same or not. The root user or dev can either disable this hashing > behaviour or use %px while debugging. I haven't figured a reason why > this is important. > > If you have something, I am all yours. If not, I poke networking next > week and try to remove this entirely. I am all for removing the restricted pointers stuff. IMHO, it has been obsoleted by the generic hashing but it has never been officially mentioned anywhere. I hope that networking guys would take it. Best Regards, Petr