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
| ||
|
Date: Mon, 2 Nov 2020 08:53:41 -0500 From: Phil Auld <pauld@...hat.com> To: David Laight <David.Laight@...lab.com> Cc: 'Benjamin Segall' <bsegall@...gle.com>, Hui Su <sh_def@....com>, "mingo@...hat.com" <mingo@...hat.com>, "peterz@...radead.org" <peterz@...radead.org>, "juri.lelli@...hat.com" <juri.lelli@...hat.com>, "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>, "dietmar.eggemann@....com" <dietmar.eggemann@....com>, "rostedt@...dmis.org" <rostedt@...dmis.org>, "mgorman@...e.de" <mgorman@...e.de>, "bristot@...hat.com" <bristot@...hat.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] sched/fair: remove the spin_lock operations On Fri, Oct 30, 2020 at 10:16:29PM +0000 David Laight wrote: > From: Benjamin Segall > > Sent: 30 October 2020 18:48 > > > > Hui Su <sh_def@....com> writes: > > > > > Since 'ab93a4bc955b ("sched/fair: Remove > > > distribute_running fromCFS bandwidth")',there is > > > nothing to protect between raw_spin_lock_irqsave/store() > > > in do_sched_cfs_slack_timer(). > > > > > > So remove it. > > > > Reviewed-by: Ben Segall <bsegall@...gle.com> > > > > (I might nitpick the subject to be clear that it should be trivial > > because the lock area is empty, or call them dead or something, but it's > > not all that important) > > I don't know about this case, but a lock+unlock can be used > to ensure that nothing else holds the lock when acquiring > the lock requires another lock be held. > > So if the normal sequence is: > lock(table) > # lookup item > lock(item) > unlock(table) > .... > unlock(item) > > Then it can make sense to do: > lock(table) > lock(item) > unlock(item) > .... > unlock(table) > > although that ought to deserve a comment. > Nah, this one used to be like this : raw_spin_lock_irqsave(&cfs_b->lock, flags); lsub_positive(&cfs_b->runtime, runtime); cfs_b->distribute_running = 0; raw_spin_unlock_irqrestore(&cfs_b->lock, flags); It's just a leftover. I agree that if it was there for some other purpose that it would really need a comment. In this case, it's an artifact of patch-based development I think. Cheers, Phil > avid > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > --
Powered by blists - more mailing lists