Revision 712f3147aee0fbbbbed2da20b21b272c5505125e authored by Linus Torvalds on 13 May 2011, 23:16:41 UTC, committed by Linus Torvalds on 14 May 2011, 17:23:44 UTC
When a register_framebuffer() call results in us removing old
conflicting framebuffers, the new registration_lock doesn't protect that
situation.  And we can't just add the same locking to the function,
because these functions call each other: register_framebuffer() calls
remove_conflicting_framebuffers, which in turn calls
unregister_framebuffer for any conflicting entry.

In order to fix it, this just creates wrapper functions around all three
functions and makes the versions that actually do the work be called
"do_xxx()", leaving just the wrapper that gets the lock and calls the
worker function.

So the rule becomes simply that "do_xxxx()" has to be called with the
lock held, and now do_register_framebuffer() can just call
do_remove_conflicting_framebuffers(), and that in turn can call
_do_unregister_framebuffer(), and there is no deadlock, and we can hold
the registration lock over the whole sequence, fixing the races.

It also makes error cases simpler, and fixes one situation where we
would return from unregister_framebuffer() without releasing the lock,
pointed out by Bruno Prémont.

Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Tested-by: Anca Emanuel <anca.emanuel@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1 parent c47747f
Raw File
TODO
Steve's quick list of things that need finishing off:
[they are in no particular order and range from the trivial to the long winded]

 o Proper timeouts on each neighbour (in routing mode) rather than
   just the 60 second On-Ethernet cache value.

 o Support for X.25 linklayer

 o Support for DDCMP link layer

 o The DDCMP device itself

 o PPP support (rfc1762)

 o Lots of testing with real applications

 o Verify errors etc. against POSIX 1003.1g (draft)

 o Using send/recvmsg() to get at connect/disconnect data (POSIX 1003.1g) 
   [maybe this should be done at socket level... the control data in the
    send/recvmsg() calls should simply be a vector of set/getsockopt()
    calls]

 o check MSG_CTRUNC is set where it should be.

 o Find all the commonality between DECnet and IPv4 routing code and extract 
   it into a small library of routines. [probably a project for 2.7.xx]

 o Add perfect socket hashing - an idea suggested by Paul Koning. Currently
   we have a half-way house scheme which seems to work reasonably well, but
   the full scheme is still worth implementing, its not not top of my list
   right now.

 o Add session control message flow control

 o Add NSP message flow control

 o DECnet sendpages() function

 o AIO for DECnet

back to top