linux-kernel - Re: [patch 1/4] spinlock: lockbreak cleanup

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: <20071101154636.GA11723@elte.hu>
Date:	Thu, 1 Nov 2007 16:46:36 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Lee Schermerhorn <Lee.Schermerhorn@...com>
Cc:	Nick Piggin <npiggin@...e.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <ak@...e.de>, riel <riel@...hat.com>
Subject: Re: [patch 1/4] spinlock: lockbreak cleanup


* Lee Schermerhorn <Lee.Schermerhorn@...com> wrote:

> > I guess it was done to make the "template" hacks eaiser. I don't 
> > really find that in good taste, especially for important core 
> > infrastructure. Anyway.
> 
> Actually, what I had/have is a cond_resched_rwlock() that I needed to 
> convert the i_mmap_lock() to rw for testing reclaim scalability.  
> [I've seen a large system running an Oracle OLTP load hang spitting 
> "cpu soft lockup" messages with all cpus spinning on a i_mmap_lock 
> spin lock.] One of the i_mmap_lock paths uses cond_resched_lock() for 
> spin locks. To do a straight forward conversion [and maybe that isn't 
> the right approach], I created the cond_resched_rwlock() function by 
> generalizing the cond_sched_lock() code and creating both spin and rw 
> lock wrappers. I took advantage of the fact that, currently, 
> need_lockbreak() is a macro and that both spin and rw locks have/had 
> the break_lock member. Typesafe functions would probably be 
> preferrable, if we want to keep break_lock for rw spin locks.
> 
> Here's the most recent posting:
> 
> 	http://marc.info/?l=linux-mm&m=118980356306014&w=4
> 
> See the changes to sched.[ch].  Should apply to 23-mm1 with offsets 
> and minor fixup in fs/inode.c.

yep. I'm too in favor of keeping the need-lockbreak mechanism and its 
type-insensitive data structure. We've got way too many locking 
primitives and keeping them all sorted is nontrivial already. I wouldnt 
mind seeing the need_lockbreak flag move into one of the high bits of 
spinlocks though, to compress size.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/