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:
 <GV1PR08MB105217A184D21CA8FB7C4E6BFFB292@GV1PR08MB10521.eurprd08.prod.outlook.com>
Date: Thu, 28 Nov 2024 06:39:37 +0000
From: Yeo Reum Yun <YeoReum.Yun@....com>
To: James Clark <james.clark@...aro.org>, Suzuki Poulose
	<Suzuki.Poulose@....com>, "mike.leach@...aro.org" <mike.leach@...aro.org>
CC: "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>,
	"alexander.shishkin@...ux.intel.com" <alexander.shishkin@...ux.intel.com>,
	"bigeasy@...utronix.de" <bigeasy@...utronix.de>, "clrkwllms@...nel.org"
	<clrkwllms@...nel.org>, "rostedt@...dmis.org" <rostedt@...dmis.org>
Subject: Re: [PATCH 2/9] coresight-etm4x: change etmv4_drvdata spinlock type
 to raw_spinlock_t

Hi James,

> There's a lot of churn in this function just to use the new scoped
> guard, but there was only one lock and unlock anyway. There are a few
> other cases of this in the whole set.
>
> The scoped guards make it easier to write correct code, but I'm not sure
> we gain anything here other than a bigger diff and more to review by
> changing already working code. Having said that I did review all the
> changes and I'm pretty sure they're all ok, so I'm on the fence about
> whether it's worth going back and undoing all of them.
>
> Surely updating to raw spinlocks is a search and replace to fix a
> specific problem, and the scoped guard stuff can be done on a case by
> case basis when anything is re-written in the future?
> 
> I don't know if we're considering a fixes tag, if PREEMPT_RT is 6.12?
> It's probably not necessary but if so we definitely want to minimise the
> change.

At first, thanks to review :) and as you said there's no functional change
except change of locktype.

But I thougt making seperate patchset to change locktype and
apply scoped_guard to two patchset makes people do duplicate review for
the same code and almost same posittion.

Since there's no functional change and reviewed,
I think it doesn't need to seperate..?

Thanks. 




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ