linux-kernel - Re: [rfc][patch 2/2] x86

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: <20070716101828.GE21464@wotan.suse.de>
Date:	Mon, 16 Jul 2007 12:18:28 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andi Kleen <ak@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [rfc][patch 2/2] x86_64: FIFO ticket spinlocks

On Mon, Jul 16, 2007 at 11:49:40AM +0200, Ingo Molnar wrote:
> 
> * Nick Piggin <npiggin@...e.de> wrote:
> 
> > On Mon, Jul 16, 2007 at 11:26:46AM +0200, Ingo Molnar wrote:
> > > 
> > > * Nick Piggin <npiggin@...e.de> wrote:
> > > 
> > > > [...] trylock is more significantly slower, but they are relatively 
> > > > rare.
> > > 
> > > trylock is the main thing that the spinlock debugging code uses, and 
> > > SPINLOCK_DEBUG is frequently enabled by distro kernels. OTOH, the cost 
> > > looks like to be +5 instructions, right? Still ...
> > 
> > Which trylocks do you mean? The lockbreak spinlocks use trylock, but 
> > those are not used with the ticket version.
> 
> the trylocks in lib/spinlock-debug.c:
> 
>  static void __spin_lock_debug(spinlock_t *lock)
>  {
>  ...
>                          if (__raw_spin_trylock(&lock->raw_lock))
>                                  return;
>  ...
>  void _raw_spin_lock(spinlock_t *lock)
>  {
>          debug_spin_lock_before(lock);
>          if (unlikely(!__raw_spin_trylock(&lock->raw_lock)))
>                  __spin_lock_debug(lock);
>          debug_spin_lock_after(lock);
>  }
> 
> am i missing something?

No, I missed that. Yeah, that would get a bit slower, but I'm not sure
if it would be a problem on a kernel where you have spinlock debuggin
on anyway.

If it becomes a problem, we could perhaps do a version for ticket locks
that first takes a ticket, and then is for up to a second before
printing the stuck lock message. That would make the performance hit go away.

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