Race in rpc__cn_network_receiver()?

Luke Kenneth Casson Leighton lkcl at lkcl.net
Thu Apr 20 03:33:29 CDT 2006


On Thu, Apr 20, 2006 at 03:04:21PM +1000, Luke Howard wrote:
 
 luke, you are a star: thank you for helping out with this.

 just for people's information (in case it's not been mentioned here - i
 must admit i forgot to notify opendce at opengroup.org!)

 about 6-8 months ago i did a coding-spree on freedce, with a view to
 achieving two, maybe three, major things:

 1) porting to win32 (if you use pthreads-win32)

 2) using posix final draft (7?) threads not posix draft 4.

 3) proving to the people on wine and reactos that they have
    a hell of a lot of work to do (measured in man-decades)
    by not using the open group's DCE/RPC reference
    implementation.
 
 here's the gotchas that i encountered, and had to give up:

 - udp worked, but tcp did not

 - reactos had some problems at the time with the code behind
   ipconfig.exe (NetTransportEnum i think it was)

 - pthreads-win32 was too strictly posix compliant (!)
   and there is a cancellation exception or something which
   makes it fail in the dcethreads exception library tests,
   where linux does not fail (!)
   
   maybe this is related to what lukeh is talking about.
   *shrug*.

 anyway, the upshot is that freedce/latest-cvs also doesn't work
 on TCP, and thank you so much people for helping track down why.

 it's only been ten years so far: hopefully some time within the next
 decade, freedce will be used for some real MSRPC-related free
 software projects.

 l


> >In rpc__cn_network_receiver(), rpc__socket_close() is called without an
> >exception handler in place. According to IEEE Std 1003.1 (2004), close()
> >is a cancellation point, see:
> >
> >http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html
> >
> >Given this, a receiver thread could receive a cancel whilst closing the
> >socket, which will cause to entire program to abort. (We have seen this
> >occur when the RPC server is under load.)
> >
> >A suggested fix is to move the call to rpc__socket_close() inside the
> >TRY/CATCH_ALL block that removes any pending cancels.
> 
> It seems like the real fix is to disable cancellation within
> rpc__socket_close(), because in other places the OSF code appears to
> assume that this is not a cancellation point.
> 
> Ditto for open(), socket(), etc (but not I/O routines that may block).
> 
> I should note that the Linux dcethreads library does actually disable
> cancellation for these calls, however in our own DCE thread library
> we opted not to override any system calls to avoid changing semantics
> when used by non-DCE code.
> 
> -- Luke
> 
> --
> 

-- 
--
lkcl.net - mad free software computer person, visionary and poet.
--



More information about the wine-devel mailing list