linux-kernel - Re: RFC on fixing mutex spinning on owner

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: <20160317101823.GQ6344@twins.programming.kicks-ass.net>
Date:	Thu, 17 Mar 2016 11:18:23 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Nicholas Mc Guire <der.herr@...r.at>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Joel Fernandes <agnel.joel@...il.com>,
	Greg Kroah-Hartman <greg@...ah.com>,
	linux-rt-users@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	kernelnewbies <kernelnewbies@...linux.org>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: RFC on fixing mutex spinning on owner

On Thu, Mar 17, 2016 at 08:05:26AM +0000, Nicholas Mc Guire wrote:
> scanning for that patter with a quite relaxed spatch did not
> turn up more than a hand full:
> 
> @resched_spin exists@
> position p;
> @@
> 
> (
> * while@p (...) {
>           ...
>           if (need_resched() || ...)
>                   break;
>           ...
>           \(cpu_relax\|cpu_relax_lowlatency\)();
>   }
> |
> * while@p (!need_resched()) {
>           ...
>           \(cpu_relax\|cpu_relax_lowlatency\)();
>   }
> )
> 
> @script:python@
> p << resched_spin.p;
> @@
> print "%s:%s " % (p[0].file,p[0].line)                                          
> 
> 
> is this making some wrong assumptions here or is this
> really so infrequent ? 

Ah, a tool, nice! :-)

There should be one in the osq_lock, one in mutex, one in rwsem-xadd,
davidlohr was adding one to rt_mutex; and these are the one I can
remember from the top of my head.

But I would not be surprised if there are a fair few more. Also for (;;)
is a frequent loop pattern.

My biggest worry is how to not forget adding this annotation if we
create yet another instance of this. The tool could help I suppose.

Also, maybe the tracer should measure the time from need_resched()
getting true until the next preemption point, instead of the entire time
preemption was disabled. Which would avoid the entire issue altogether.