linux-kernel - Re: [PATCH 1/9] coresight: change coresight_device lock type to raw_spinlock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241202103853.26db0c13@gandalf.local.home>
Date: Mon, 2 Dec 2024 10:38:53 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Yeo Reum Yun <YeoReum.Yun@....com>
Cc: Suzuki Poulose <Suzuki.Poulose@....com>, "mike.leach@...aro.org"
 <mike.leach@...aro.org>, "james.clark@...aro.org" <james.clark@...aro.org>,
 "alexander.shishkin@...ux.intel.com" <alexander.shishkin@...ux.intel.com>,
 "bigeasy@...utronix.de" <bigeasy@...utronix.de>, "clrkwllms@...nel.org"
 <clrkwllms@...nel.org>, "coresight@...ts.linaro.org"
 <coresight@...ts.linaro.org>, "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "linux-rt-devel@...ts.linux.dev"
 <linux-rt-devel@...ts.linux.dev>, nd <nd@....com>
Subject: Re: [PATCH 1/9] coresight: change coresight_device lock type to
 raw_spinlock_t

On Thu, 28 Nov 2024 07:39:22 +0000
Yeo Reum Yun <YeoReum.Yun@....com> wrote:

> Hi Steven,
> 
> > We should start documenting what is not real-time "safe". That is, if this
> > code is executed, we have a loop here that holds a raw spin lock. This
> > appears to make the time the raw spin lock held to be non deterministic.
> > 
> > If someone is running PREEMPT_RT and expects deterministic behavior, they
> > cannot be using this code. That is fine, but we should probably create a
> > document somewhere that notes this.
> >
> > -- Steve  
> 
> I think it's quite deterministic becase the number of loop currently
> determined by the number of preload_feats.
> 
> Also, I don't think the number of  feats will be loaded as much as
> it can do undeterministic behavior since 
> the number is not many and it is quite predictable.

Still should be documented somewhere. It should describe the maximum number
of feats that will ever be loaded. If there's a max, it makes it back to
O(1). With a 'k' of how long it takes to process the max number of feats.

-- Steve