From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) by sourceware.org (Postfix) with ESMTPS id 2486D384A02E for ; Thu, 5 Nov 2020 17:21:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2486D384A02E Authentication-Results: sourceware.org; dmarc=none (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 (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MWAf4-1kqhXL3EDq-00XbJ9 for ; Thu, 05 Nov 2020 18:21:41 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id ADC57A80DF4; Thu, 5 Nov 2020 18:21:40 +0100 (CET) Date: Thu, 5 Nov 2020 18:21:40 +0100 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: AF_UNIX status report Message-ID: <20201105172140.GP33165@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <1d0ea5dc-7e9b-d8fe-5f6e-da7a799a3b13@cornell.edu> <20201027094340.GJ5492@calimero.vinschen.de> <0f945b4c-aa30-e08e-9f86-d4b41279ba10@pismotec.com> <20201030092019.GW5492@calimero.vinschen.de> <38e33f7a-e87d-fea8-ac9e-826f94c189d4@cornell.edu> <20201104120304.GF33165@calimero.vinschen.de> <88b3dfe6-a67d-c597-afe2-4edb13cee5d7@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <88b3dfe6-a67d-c597-afe2-4edb13cee5d7@cornell.edu> X-Provags-ID: V03:K1:1ApuQNvrAI8Icb2MFbsADi7ZL2uZkOYrGNf+sRZRh5WSs3XW0q2 nWsJ6+HNwq53vVIlh3IAZpN9POTUz3bJT9kZdCB+rYSm4oxnNZx/5CY8rHJYFo96dyMi3RW EgPKmt0jyqXn3rgFgWVId10BNTslqrQidlzKQ7gxAzSw4K3+mnt8A5uD0JUEjXVFoXHn9/V WWaYsmbuISb/hYQ3EMRvA== X-UI-Out-Filterresults: notjunk:1;V03:K0:LrPbUrHy/qs=:Lh99sSmW2stZRTtFhOgetO R/A0nRmqg3pT7VRCkl+Yix/t13oinWxCtOBYdK9SZh5criRj5Ew7OIVajzsWnOcA/+u6AjYgt 0rWANB7juA8C2gSdds6iqZ69C2xwD30+kintAxISdSxH7gydZv7Ro5VYQJnuSpVsNRtVQRfOz XYrNMJVyLYwEwVQf1unMfh2E0EPyR2Bi6yHX5vyaywFkjP1go8xqhxLuioSnDi7xDjPCwjB+j +l8Y8TaP/NwMld+p6R7mV5iB6u+4kQ48ZB9RZENZj98dc0zmcA+1rRrX2Id7Km2RW0t2InwIn FCsdKlNftsutnApeUg7Pdv6fvoqbF0gDaYEaWI0OZlhUmsd1h6Ue1AWVXZaQeJGVEZZsVmwFB xs9lxDxIVhkjfYI4CHO0u5N5HglKasMQS0cb8E6KnbgcNwG++YzLAHISLvQter2ozovuBtmwY T92mkMhS/A== X-Spam-Status: No, score=-100.7 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, 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: Thu, 05 Nov 2020 17:21:44 -0000 On Nov 5 09:23, Ken Brown via Cygwin-developers wrote: > OK, here's how I imagine this working: > > A process wants to send a file descriptor fd, so it creates a msghdr with an > SCM_RIGHTS cmsghdr and calls sendmsg. The latter creates and sends an admin > packet A containing the fhandler for fd, and then it sends the original > packet P. > > At the receiving end, recvmsg sees packet A first (recvmsg is always > checking for admin packets anyway whenever it's called). It stores the > fhandler somewhere. When it then reads packet P, it retrieves the stored > fhandler, fiddles with it (duplicating handles, etc.), and creates the new > file descriptor. Actually, this needs to be implemented in a source/dest-independent manner. Only the server of the named pipe can impersonate the client. So the server side should do the job of duplicating the handles. If the sever is also the source of SCM_RIGHTS, it should send the fhandler with already duplicated handles. > Does this seem reasonable? The main thing bothering me is the lack of > atomicity. I don't like the gap between the sending of the two packets A > and P, and similarly for the receiving. I thought about using the io_lock > to at least make sure that the two packets are adjacent in the pipe, but I > don't know if we want to tie up the io_lock for that long. > > Also, the sending process might be sending several file descriptors at once, > so that there would be several admin packets to be sent (unless we want to > cram it all into one). We can safely assume that pipe packets up to 64K are sent and received atomically. In most cases this shouldn't be much of a problem. Most scenarios using SCM_RIGHTS send no or only a minor payload. Most scenarios share a single or only a handful of descriptors. Apart from that, Linux also defines SCM_MAX_FD, the max. number of descriptors in a single sendmsg call. If the number of descriptors is larger, sendmsg returns EINVAL. SCM_MAX_FD is 253 on Linux, but What that means to us is, we can choose our own SCM_MAX_FD and just return EINVAL if the number of descriptors is uncomfortably high. The max. number of descriptors should be limited so that all descriptors fit into 64K, or even 32K, just to leave space for payload. Assuming a size of about 600 bytes per fhandler, 50 might be a good candidate for SCM_MAX_FD. I'd say even 32 would be sufficent for most scenarios. The idea would be to create the packet on the source side with all fhandlers in the ancilliary data block, followed by the payload. This should typically fit in a 64K package. If not, only the payload needs to be split into multiple packages. Do we really need atomicity there? Not sure, but only then we'd need an io_lock. Does that make sense? Thanks, Corinna