linux-kernel - Re: spinlock which can morph into a mutex

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:	Fri, 18 Dec 2009 18:14:29 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Miquel van Smoorenburg <miquels@...tron.nl>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: spinlock which can morph into a mutex

On Fri, 18 Dec 2009, Miquel van Smoorenburg wrote:

> I'm trying to implement a dynamically resizable hashtable, and
> I have found that after resizing the table I need to call
> synchronize_rcu() and finish up before letting other writers
> (inserts, deletes) access the table.
> 
> Ofcourse during the hashtable update a spinlock is held to
> exclude the other writers. But I cannot hold this spinlock over
> synchronize_rcu(), yet the other writers still need to be excluded.
> 
> So I probably need a mutex instead of a spinlock, but I want to
> keep minimal overhead for the common case (when no resizing is in
> progress).  I think I need a spinlock that can morph into a mutex ..

Is the writer frequency and the possible contention so high that you
need a spinlock at all ?
 
> I was thinking about using something like the code below.
> It is sortof like a spinlock, but it's ofcourse less fair
> than actual ticketed spinlocks.
> 
> I'm working off 2.6.27 at the moment, but I noticed that in
> 2.6.28 adaptive spinning was introduced for mutexes. Is the
> approach below still worth it with adaptive spinning or could
> I just convert the spinlocks to mutexes with minimal extra overhead ?

Test it :)

If the mutex is still to heavy weight for you, then you can solve it
without implementing another weird concurrency control:

writer side:

       spin_lock(&hash_lock);

       if (unlikely(hash_update_active)) {
       	  spin_unlock(&hash_lock);
       	  wait_event_(un)interruptible(&hash_wq, !hash_update_active);
	  spin_lock(&hash_lock);
       }

resize side:

       spin_lock(&hash_lock);
       hash_update_active = 1;
       ....
       spin_unlock(&hash_lock);
       synchronize_rcu();
       hash_update_active = 0;
       wake_up(&hash_wq);

Thanks,

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