lkml.org 
[lkml]   [2009]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ib-release-locks-in-the-proper-order
From
Date
On Mon, 2009-09-21 at 21:35 +0200, John Kacur wrote:
> Please consider the following patch - originally from Steven Rostedt.
> It solves a problem for rt which is very sensitive to the lock ordering.
> It should have a no impact on non-rt.
>
> The patch applies to current tip/master - but it is fine with me if it
> would be more appropriate for one of the infiniband people to take it.
>
> Thanks
>
> >From e533f2b9ee9b0bd95aaa4c3369e79b350c9895d3 Mon Sep 17 00:00:00 2001
> From: Steven Rostedt <srostedt@redhat.com>
> Date: Mon, 21 Sep 2009 21:23:46 +0200
> Subject: [PATCH] ib: release locks in the proper order
>
> RT is very sensitive to the order locks are taken and released
> wrt read write locks. We must do
>
> lock(a);
> lock(b);
> lock(c);
>
> [...]
>
> unlock(c);
> unlock(b);
> unlock(a);
>
> otherwise bad things can happen.
>
> Signed-off-by: Ken Cox <jkc@redhat.com>
> Signed-off-by: Clark Williams <williams@redhat.com>
> Signed-off-by: John Kacur <jkacur@redhat.com>

The -rt patch doesn't use the multi rwlock code anymore (the reason for
the first patch), and the last revision of that code was able to handle
that too.

Linus totally ripped into this idea. A lock must be able to handle any
order of unlocking. There should be no technical reason a lock must be
unlocked in reverse order they were locked.

What exactly is sensitive about this?

-- Steve




\
 
 \ /
  Last update: 2009-09-21 23:21    [W:0.224 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site