From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) by sourceware.org (Postfix) with ESMTPS id 09214393A407 for ; Mon, 3 May 2021 15:45:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 09214393A407 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=corinna-cygwin@cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1N5FMB-1lWPgO418H-011EK3 for ; Mon, 03 May 2021 17:45:34 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id DCA5FA80D64; Mon, 3 May 2021 17:45:31 +0200 (CEST) Date: Mon, 3 May 2021 17:45:31 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: The unreliability of AF_UNIX datagram sockets Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <58da34ac-f2b6-d8b2-e872-834cfcb1ab51@cornell.edu> <6cac30e5-56fc-5bf1-b85b-fe6b91bc5e97@cornell.edu> <16e1d55e-15ea-6c0e-04e4-aa6cb2c0c1bd@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:Z/t7c3rZyRyB45ibv7SieaT9qwNKtY9gwxEEzh9lOxzca95yVQE 8IJorpcQw3n9LOvyqNILkYjsxaP4Ub0dtT3njTAFF3Fvey4WTCwhv7hmO7HghYPNn2AtBgy 1FlD6MWiAJPPe4C3hfBUpjVo62ro06RTqA2qWvicu8a8kBotT6Ir5iBp6Jxq2Hlkv1ULZiU LYQOeVSxRcgbZwm+OkDfw== X-UI-Out-Filterresults: notjunk:1;V03:K0:81EcEwfvEn8=:zJMS5N5LkXT8Jokb14kV3X vtKtQVpU0tbdAewfBjZdb2SViX6OYIR3cTLiPAym3CV5WWLh156FcDzay1gZNQGT+tLdWaaq9 BlEPQO9qUjEbxDbcEGDVlWzF9bs5T3Lsfe9sX5mBxzSo4HVLiOcZYJdrD8K6XCL5YHvJDtx+8 2QsM2hqw0KN4KK91iLNYNKWRx0Z9H4uaeLGUNtho46vthSC+HJZRIiVTo0fpDMeAh3S78KYA/ JgO+SYocKI/YjMuzMoOyeO+UZrlY1LaxV4o7sX3ywO4iRKooTOTMTBcAb4GsePSXZFt6vk/e+ 7xb78TMOseO+N0ePpEqSoGbF+ZmFdhxlbBPl8PV46nnQXXoSJBkf08olfKVoyDB0lt4ro6jNI tGi2pOMjJx4emqVHc6kZwbRaa3gcKjpmfbcgRTR9FW9H2fXCRpi/61YYIHd67WZzU2XBQQfF0 jiyPMol/RDNGMBf5BTijbI/3n73rvGDKn1z2Xo42ljCnYh7Eyy8o1PBFEfMqjdmS0zBDQrqg9 ozZjZeobR8rJvZyexRhQSQ= X-Spam-Status: No, score=-100.3 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 15:45:39 -0000 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