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]
Date:	Wed, 28 Mar 2007 09:04:59 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Ravikiran G Thirumalai <kiran@...lex86.org>,
	Ingo Molnar <mingo@...e.hu>,
	Nikita Danilov <nikita@...sterfs.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] queued spinlocks (i386)

On Sun, Mar 25, 2007 at 07:54:07PM +0400, Oleg Nesterov wrote:
> I am sorry for being completely off-topic, but I've been wondering for the
> long time...
> 
> What if we replace raw_spinlock_t.slock with "struct task_struct *owner" ?
> 
> 	void _spin_lock(spinlock_t *lock)
> 	{
> 		struct task_struct *owner;
> 
> 		for (;;) {
> 			preempt_disable();
> 			if (likely(_raw_spin_trylock(lock)))
> 				break;
> 			preempt_enable();
> 
> 			while (!spin_can_lock(lock)) {
> 				rcu_read_lock();
> 				owner = lock->owner;
> 				if (owner && current->prio < owner->prio &&
> 				    !test_tsk_thread_flag(owner, TIF_NEED_RESCHED))
> 					set_tsk_thread_flag(owner, TIF_NEED_RESCHED);
> 				rcu_read_unlock();
> 				cpu_relax();
> 			}
> 		}
> 
> 		lock->owner = current;
> 	}
> 
> 	void _spin_unlock(spinlock_t *lock)
> 	{
> 		lock->owner = NULL;
> 		_raw_spin_unlock(lock);
> 		preempt_enable();
> 	}
> 
> Now we don't need need_lockbreak(lock), need_resched() is enough, and we take
> ->prio into consideration.
> 
> Makes sense? Or stupid?

Well with my queued spinlocks, all that lockbreak stuff can just come out
of the spin_lock, break_lock out of the spinlock structure, and
need_lockbreak just becomes (lock->qhead - lock->qtail > 1).


-
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/

Powered by blists - more mailing lists