public inbox for cygwin-developers@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-developers@cygwin.com
Subject: Re: The unreliability of AF_UNIX datagram sockets
Date: Mon, 3 May 2021 17:45:31 +0200	[thread overview]
Message-ID: <YJAam1OhVVkRIYu+@calimero.vinschen.de> (raw)
In-Reply-To: <YI/Q1ZQ0cllEqFUB@calimero.vinschen.de>

On May  3 12:30, Corinna Vinschen wrote:
> 1. As you noticed, the socket descriptors are inherited by exec'ed
>    children, but the mqueue isn't.  So we need at least some kind of
>    fixup_after_exec for mqueues used as part of AF_UNIX sockets.
> 
> 2. While none of the mqueue structures are propagated to child
>    processes, the handles to the synchronization objects accidentally
>    are.
> 
> 3. Note 1 and 2 can only be implemented, if we introduce a new
>    superstructure keeping track of all mdq_t/mq_info structure
>    pointers in an application.  Oh well.  Bummer, I was SOO happy
>    that the posix_ipc stuff didn't need it yet...
> 
> 4. As stated in the code comment leading the mqueue implementation,
>    I used Stevens code as the basis.  What I didn't realize so far is
>    that Stevens simplified the implementation in some ways.  The code
>    works for real POSIX mqueues, but needs some more fixing before it
>    can be used for AF_UNIX at all.
> 
> 5. I hacked a bit on an mq-only mmap call, which is supposed to allow
>    creating/opening of named shared memeory areas, but that's a tricky
>    extension to the mmap scenario.  I have a gut feeling that it's
>    better to avoid using mmap at all and use Windows section mapping
>    directly in mq_open/mq_close, especially if we have to implement
>    fixup_after_exec semantics anyway.
> 
> 6. Ultimately, AF_UNIX sockets should not run file-backed at all,
>    anyway.  Given that sockets can't be bound multiple times, there's
>    no persistency requirement for the mqueue.

Got it:

7. The idea of _mq_recv partial reads is entirely broken.  Given that
   the information in the queue consists of header info plus payload,
   the entire block has to be read, and then a new block with fixed
   header and shortened payload has to be rewritten with bumped priority.
   This in turn can only be performed by the AF_UNIX code, unless we
   expect knowledge of the AF_UNIX packet layout in the mqueue code.


Corinna

  reply	other threads:[~2021-05-03 15:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27 15:47 Ken Brown
2021-04-29 11:05 ` Corinna Vinschen
2021-04-29 11:16   ` Corinna Vinschen
2021-04-29 14:38   ` Ken Brown
2021-04-29 15:05     ` Corinna Vinschen
2021-04-29 15:18       ` Corinna Vinschen
2021-04-29 16:44       ` Ken Brown
2021-04-29 17:39         ` Corinna Vinschen
2021-05-01 21:41           ` Ken Brown
2021-05-03 10:30             ` Corinna Vinschen
2021-05-03 15:45               ` Corinna Vinschen [this message]
2021-05-03 16:56                 ` Ken Brown
2021-05-03 18:40                   ` Corinna Vinschen
2021-05-03 19:48                     ` Ken Brown
2021-05-03 20:50                       ` Ken Brown
2021-05-04 11:06                         ` Corinna Vinschen
2021-05-13 14:30                           ` Ken Brown
2021-05-17 10:26                             ` Corinna Vinschen
2021-05-17 13:02                               ` Ken Brown
2021-05-17 13:02                               ` Ken Brown
2021-05-20 13:46   ` Ken Brown
2021-05-20 19:25     ` Corinna Vinschen
2021-05-21 21:54       ` Ken Brown
2021-05-22 15:49         ` Corinna Vinschen
2021-05-22 16:50           ` Ken Brown
2021-05-22 18:21             ` Ken Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YJAam1OhVVkRIYu+@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin-developers@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).