linux-kernel - Re: semantics of reader/writer semaphores in rt patch

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-next>] [day] [month] [year] [list]

Date:	Sun, 26 Oct 2014 00:19:16 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Chris Friesen <chris.friesen@...driver.com>
cc:	rt-users <linux-rt-users@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: semantics of reader/writer semaphores in rt patch

On Thu, 23 Oct 2014, Chris Friesen wrote:

> I recently noticed that when CONFIG_PREEMPT_RT_FULL is enabled we the
> semantics change.  From "include/linux/rwsem_rt.h":
> 
>  * Note that the semantics are different from the usual
>  * Linux rw-sems, in PREEMPT_RT mode we do not allow
>  * multiple readers to hold the lock at once, we only allow
>  * a read-lock owner to read-lock recursively. This is
>  * better for latency, makes the implementation inherently
>  * fair and makes it simpler as well.
> 
> How is this valid?  It seems to me that there are any number of code paths
> that could depend on having multiple threads of execution be able to hold the
> reader lock simultaneously.  Something as simple as:
> 
> thread A:
> take rw_semaphore X for reading
> take lock Y, modify data, release lock Y
> wake up thread B
> wait on conditional protected by lock Y
> free rw_semaphore X
> 
> thread B:
> take rw_semaphore X for reading
> wait on conditional protected by lock Y
> send message to wake up thread A
> free rw_semaphore X

I don't see why B should wake A without changing the conditional. A
won't make progress by being woken by B as the conditional does not
magically change just because B wakes A.

So what you wanted to say is:

  thread B:
  take rw_semaphore X for reading
  wait on conditional protected by lock Y
+ take lock Y, modify data, release lock Y
  send message to wake up thread A
  free rw_semaphore X

Otherwise your example does not make any sense at all. And that has
some serious non RT related implications.

> In the regular kernel this would work, in the RT kernel it would deadlock.

Works by some definition of 'works'
 
> Does the RT kernel just disallow this sort of algorithm?

Yes. For a good reason. Let's add thread C

A    	   	B		C
down_read(X)
				down_write(X)
lock(Y)
modify data
unlock(Y)
wake(B)
		down_read(X)

Due to the mainline rwsem fairness semantics:

A holds X, C is blocked on A and B is blocked on A.

Deadlock, without RT and the single reader restriction being involved.

So RT does not violate ANY of the existing mainline semantics, it just
imposes a performance impact of not allowing multiple readers.

Aside of that it provides as usual the free of charge service to
expose mainline bugs faster.

Yes, it's valid and not that simple as you might think.

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/