Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/3/05, Andy Isaacson <[email protected]> wrote:

> 
> A consistent statement would be
> 
>     After fork(2), any regions which were registered are UNDEFINED.
>     Region boundaries are byte-accurate; a registration can cover just
>     part of a page, in which case the non-registered part of the page
>     has normal fork COW semantics.
> 

That is a reasonable approach.

> 
> Obviously, calling *any* RDMA-userland-stuff in the child is completely
> undefined [1].  One place where I can see a potential problem is in
> atexit()-type handlers registered by the RDMA library.  Since those
> aren't performance-critical they can and should do sanity checks with
> getpid() and/or checking with the kernel driver.
> 

That is also reasonable. None of the RDMA libraries I have worked on
bothered to use an atexit()-type hook because the user was theoretically
*required* to close the rnic, and driver code was already reuqired to clean
up in case of a total process failure. Adding an intermediate safety-net
for applications that exited cleanly but forget to close just didn't seem
worthwhile. If the application wants the cleanup performed optimally
then it can close the rnic, otherwise it can't complain about forcing
the RNIC vendor to clean up in the driver code.

> [1] You might want to allow the child to start a completely new RDMA
>     context, but I don't see that as necessary.
> 

That should be allowed. It is actually more normal to use the parent
as a dispatcher and to actually manage the connection in a child
process.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux