From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by sourceware.org (Postfix) with ESMTPS id CBFBC3858402 for ; Mon, 13 Sep 2021 20:15:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CBFBC3858402 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1N2E9Y-1n3w3s1mXu-013bYJ for ; Mon, 13 Sep 2021 22:15:26 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 91ED2A8053E; Mon, 13 Sep 2021 22:15:25 +0200 (CEST) Date: Mon, 13 Sep 2021 22:15:25 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <33386baf-3b2d-d57f-2ad3-1bd328ed7935@cornell.edu> <20210911075734.aaf37697ba7db2ad14d911a3@nifty.ne.jp> <20210911113517.f74fc3ac1971bbf04c7a9bd1@nifty.ne.jp> <695ce1f4-4f7d-f3f3-6dd3-087467d67b28@cornell.edu> <20210912174849.3d38107568065a95aeb19c7c@nifty.ne.jp> <20210912200423.667e40eb1adc52461bbefa20@nifty.ne.jp> <20210914043718.f420491c6723f3dc2e2d9753@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210914043718.f420491c6723f3dc2e2d9753@nifty.ne.jp> X-Provags-ID: V03:K1:9Fvh22BZgolntIhXHT2PxZkScxHDwJz+69pH4tX5ocFVPBsRzmX Yh2wMKzZRTG2gtdx7Xt6Sy3pqUSt9Z2qrppG5xKweNP3sDYDnZ1B/RjEe66CaDXKaiM7B/0 MLAioOvqvbPPxtwUBG/LQF0ThmoiE4/hrnGGbc3Yeguu3rJ8lYvdUBSblFFVPjpdThjArQz YnFj8TBnIIGShf32oXYOg== X-UI-Out-Filterresults: notjunk:1;V03:K0:MfwekjQ7nZY=:yWaoOntTMKqtyBQpP3gSL0 lmaBOTgPbnAD/seZyllaWhp1G9BOqTsMy8lbrjabvNEckFHLiHpqDvfqXj3OTApdQtpBccngQ TzhM4uZ/FVx5wr1c3FX1fXEHQSa5WP/G+ZsA5F0c+nlLQ3NgrL8QCosvNCztDZh0TOPo4LrXE 7kh6qhtO7GZQiScVWu1XF98+E6pQJLAZPntVPhe4x77Y/PMTlIpu19QB+d9i81ipGHwVvXx9j HW+IEsD/k5g21G9xI7uSs72aESPwhgPoWrhC5fhwybazvt6A0XpLUKCJKLAH3IT490rVGJtr0 FpYB61W3GsssP+oFSPCMrrqklUmEdspH4cURbSTEYn6k9SkJ4av3L73pbch/sXkHbPYQAlHI2 5In2riVS9J11ZHfokN5Ns+MBvpDBg63iwbDfLB90CmnC82/0GtcQGwpnHwlUKm3uyQAPdo7ta jNjwrxUl/s8J57AcRqMKdZk/nW5XCm0uBAQ8z11gRUioNok94L+04WsD0RpLHihK1mfgl+kVd gwlKWlsQmgzK8vCMuYhPOmw7iuolGmrVLwTtPV9o1ti8GKf+rZrwKFSMGzpbRzjI+GRpl9XoX KNJpo2s+6I9XuDAD03ggJOHfcvANsXmRdekeAZUfzICo8tHi6G5YvEwMAzhGaDHWPdI3gjQVe +6WdMOQIXzB65NJQ8Iy1ig7q4KyGEulR8yhCRGTfUNo+ZGWM0HcG63izT3fCISoxWEtpk4NaC 9i7fysLKAs/SjIfJ/h8KsiVs3hj9gHUYjilr0zKYQIA1u2/aPH8WOC7jNm0= X-Spam-Status: No, score=-99.6 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 13 Sep 2021 20:15:29 -0000 On Sep 14 04:37, Takashi Yano wrote: > On Mon, 13 Sep 2021 20:32:33 +0200 > Corinna Vinschen wrote: > > Btw., while looking into the current pipe code, I wonder what select_sem > > is doing in the pipe code at all so far. It gets released, but it never > > gets waited on?!? Am I missing something? > > The semaphore is waited in select.cc. Ouch, I missed the get_select_sem call, sorry. > > I don't understand why calling fork_fixup on query_hdl should depend > > on the handle count. If you duplicate a writer, you always have to > > duplicate query_hdl as well to keep the count, no? Inheritence is > > handled by the O_CLOEXEC flag and fork_fixup will do the right thing. > > I thought so, however, counting query_hdl cannot work as expected > without this check. The number of query_hdl opend seems to exceed > the number of writer. If the write handle as well as the query handle are both opened, duplicated and closed in the same manner, they should never have a different count, unless the write side is inherited by a non-Cygwin client. > There seems to be the case that handle is already inherited here > without fork_fixup. Any idea? That should depend on the O_CLOEXEC setting, but identically for all handles in the fhandler. I pushed two more patches to topic/pipe in terms of inheritence, maybe that gives a clue? > > > > > + if (!DuplicateHandle (GetCurrentProcess (), r, > > > + GetCurrentProcess (), &fhs[1]->query_hdl, > > > + GENERIC_READ, !(mode & O_CLOEXEC), 0)) > > > > This is a bug I introduced accidentally during testing. This > > GENERIC_READ is actually supposed to be a FILE_READ_ATTRIBUTES. > > Sorry about that. > > The PoC code uses PeekNamedPipe for query_hdl, so GENERIC_READ is > necessary I think. Oh, right, that's how it's documented. Funny enough, the descriptions of FSCTL_PIPE_PEEK does not mention any permissions at all. I tried the permissions and it's FILE_READ_DATA which is required. Thanks, Corinna