From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2115.outbound.protection.outlook.com [40.107.220.115]) by sourceware.org (Postfix) with ESMTPS id DB0B13857813 for ; Thu, 5 Nov 2020 19:01:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DB0B13857813 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WcGudkjmEfjyWRnJuO/5dDn9i4b677qZw5j1oKKghxlRPGoER6G3eh+ZB+e8lssB6wL3GOd+DS7HHJN5VvHpTu8mBI/a4W/dNOIU6G5NCnMOSMF8J+n+wJfhz+9/gjdj/p3YrTCAKIpLp38xT3MFHJSrBptPT4PIvLZbTlk90wSYUgqNIbtDSb72YkKpjeLPQOUa9oSkWbAH9NpZQpzjGj2fYT66Fv+WgNnybAeawHf2B+zejtWw9GMWFVToAT0Yzy5421fBxzSoGG71wCmzTYdQz4KKezQjBz8a6Y9I1Hfo/oPLXoZiaZtgf0NyVSwzSMSWidEQFLvNKTcQo6tDDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FkwQxT8KnJZtNxuQbU87cpmzSDspfQnGO2d7x3v5hOA=; b=D3W/ox0dsuJLLsx6RPhVXZSG2QhC/E2RV1mcD5bcXwEoVCfN2QqTMoKOrHMZfFd5dLOdbcumsGTzDrAhIShRWhJ3uiy6OZji+7T/sIzFIt/uHH7tfVo2cjdd0df4bWlPmNS/UwZSEQ2iHhu77jyQApfiCFoCEZpisUTl+FHkVMAyt7Dy6zloo3dsHiMQrD9lOdUzd9TeeUmu8pxcnkVkra8/gyrFHxP30OUNRtLjhwEDXWDBe7cl1t6cWR50tTfTUra0SVrzOvqgg19yZ1E3UVviMd4SPtQ7Du7DnB1nrBs1aWwcXuCjF/JuvTG42cLgip0b0fwuJ3uPFTvNtlO/tQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cornell.edu; dmarc=pass action=none header.from=cornell.edu; dkim=pass header.d=cornell.edu; arc=none Received: from MN2PR04MB6176.namprd04.prod.outlook.com (2603:10b6:208:e3::13) by MN2PR04MB5647.namprd04.prod.outlook.com (2603:10b6:208:3f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Thu, 5 Nov 2020 19:01:18 +0000 Received: from MN2PR04MB6176.namprd04.prod.outlook.com ([fe80::113e:c874:1207:eca8]) by MN2PR04MB6176.namprd04.prod.outlook.com ([fe80::113e:c874:1207:eca8%6]) with mapi id 15.20.3541.021; Thu, 5 Nov 2020 19:01:18 +0000 Subject: Re: AF_UNIX status report 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> <20201105172140.GP33165@calimero.vinschen.de> From: Ken Brown Message-ID: <90fdecee-fb2d-6b24-ef30-356df2dbc3d2@cornell.edu> Date: Thu, 5 Nov 2020 14:01:16 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 In-Reply-To: <20201105172140.GP33165@calimero.vinschen.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [2604:6000:b407:7f00:4d7:217c:b95e:420c] X-ClientProxiedBy: MN2PR07CA0015.namprd07.prod.outlook.com (2603:10b6:208:1a0::25) To MN2PR04MB6176.namprd04.prod.outlook.com (2603:10b6:208:e3::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2604:6000:b407:7f00:4d7:217c:b95e:420c] (2604:6000:b407:7f00:4d7:217c:b95e:420c) by MN2PR07CA0015.namprd07.prod.outlook.com (2603:10b6:208:1a0::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Thu, 5 Nov 2020 19:01:17 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a2733c1e-61f6-4e6d-38b8-08d881bd2d2c X-MS-TrafficTypeDiagnostic: MN2PR04MB5647: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: q5lqqoDWbcLIi+MjHmkwGixi7BmVvm2hCpmOwZr5IY9c5poWh5Ibzb+algNfkvJ8ON6MolaCtSEteVX9EB6Iq8b0XzClRA6+RN3ynsJunp8YkIEQfjhGv64TEUbS58Mf0kU42NyThBLQGRrym0iZYZAblyNOb8xqjlDe+q4RXwI4Fmz1DpwOKx2NfstT3QlXDarCfWWWXN68kxSIK59caP579AoD67vRF8Si9gLqUs3D+tfm6YrqSTiqEKUqm62lcp12HV7T2CkrsJm5mZRRMbd3CtTKhKa9/4UAYjj95ZetWyBM2haUs1BsMz1k3UjTjvqZcafvqcA9npSOQMBLsIwns1yD5HqxDucwWGrCNcJouvEh4DA+nebaxU+luR8m X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR04MB6176.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(396003)(366004)(39860400002)(376002)(31686004)(2906002)(6486002)(8936002)(66556008)(6916009)(31696002)(66946007)(478600001)(66476007)(5660300002)(186003)(75432002)(36756003)(2616005)(83380400001)(16526019)(86362001)(8676002)(7116003)(316002)(786003)(52116002)(53546011)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: oUiaYq8eIH6MgrthSqvdjhMlceopGcnhbglAgHKBKudUqQRk42jN01JArj8dtOOQuv7+zjSuTKwrX3ZHSinfmcVwNOrKOTdTuZJ15tuT98xmSlGXRd7RHHGBiSJVuxKbyj0bEwzeZzBoqCzfdm4mGZI1KsFNCOskB8PYhoKSvcZ4ZSyZjC4EapO/bIs1FbD6c2yLnI3Jm7IeJ1KKRj+lqSycF1v9LJTN4QQKzNQlnMqvk26Jj3+TiRdpz84E0dXFkfv+SdjJHmJl9hIZdBKnYrikfG9j5Cz6n7wHhyEcErtNyOU00KqCZ45DILO22BzS8MELZhAuP+a3HHpWRN3JZFUmAV1F8cYdihn3bE0/Lqoqyor8nukZ+3ESWEqT15xdObRG5uMbQ9F0MqG5ReEiaRrPKcC1muhBgVU+7BjBQv/iq9bHKIOiqaS2f0Ad9Zqs3NZ3Leh1DpQttW5blMQnUq9bnGgh0hSSJpr8eSOUzgai4xnKiv7wVkf/5vRMMVkMOKuytPma/kBzwRcdBIapskXHnVw+qFW2anPvDj3+oDUBVROUJ8Jd8h0zb2ux7tAmcn+4yOpFjWRlYytvpVU0NjmMkDIPEqK5xQJVOcuLfwA5Ychw/rThumiQv3kpnLK8SyzGCt3gWt89GcPp2svAM6icrCRWevjhIf6u5gwhATOEhxImcWqBt0nv2HdrMuzpT/Y2hfNBjcF14pp8NZuNnQ== X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: a2733c1e-61f6-4e6d-38b8-08d881bd2d2c X-MS-Exchange-CrossTenant-AuthSource: MN2PR04MB6176.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Nov 2020 19:01:18.1089 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d7e4366-1b9b-45cf-8e79-b14b27df46e1 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: YIZrXcfbMzeZ403U7o0eOtR6FygmxHadNgEh/R5/8wtarplvd7qcfJXBJExlxXFmDMpkgwGkaUkiEyLIci2FZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR04MB5647 X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, 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 19:01:25 -0000 On 11/5/2020 12:21 PM, Corinna Vinschen wrote: > 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. Ah, OK. I was thinking of it differently. Rather than having the server impersonate the client, I was thinking that the sender would send its winpid as part of its admin packet, which the receiver could then use to get a handle to the sender's process. The receiver could then duplicate the handles. But maybe your approach is better. I'll have to rethink it. >> 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? Yes. Thanks. Ken