From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63489 invoked by alias); 17 Nov 2016 15:24:33 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 63464 invoked by uid 89); 17 Nov 2016 15:24:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=cancel X-HELO: mx1.redhat.com Subject: Re: [PATCH v7] getrandom system call wrapper [BZ #17252] To: Zack Weinberg References: <3dd5d3b8-c196-98fb-1671-90cd90ab90c7@redhat.com> <244f578c-889a-a4cf-c686-bb2a5e49cca1@panix.com> <2d175242-1a82-9410-d01e-682ab4d9081e@panix.com> <0cca2fc9-14d2-9fa2-5a6e-fe00af31acd6@redhat.com> <4928b864-9691-021d-fcf9-b3ef9bd10f63@panix.com> Cc: GNU C Library From: Florian Weimer Message-ID: <5193b776-03a5-3841-6980-b67c56a99c2a@redhat.com> Date: Thu, 17 Nov 2016 15:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00629.txt.bz2 On 11/17/2016 02:56 PM, Zack Weinberg wrote: > On 11/17/2016 08:50 AM, Florian Weimer wrote: >> On 11/17/2016 02:45 PM, Zack Weinberg wrote: >>> On 11/17/2016 08:02 AM, Florian Weimer wrote: >>>> On 11/16/2016 05:41 PM, Zack Weinberg wrote: >>>>> On Wed, Nov 16, 2016 at 10:52 AM, Florian Weimer >>>>> wrote: >>>>>> On 11/16/2016 04:20 PM, Zack Weinberg wrote: >>>>>>> I am seriously considering escalating my disagreement here to a >>>>>>> formal objection. I would like to know why you think it is >>>>>>> NECESSARY - not merely convenient or consistent with other stuff - >>>>>>> for this function to be a cancellation point. >>>>>> >>>>>> It's necessary if you ever want to cancel a hanging getrandom in a >>>>>> context where you cannot install a signal handler (so that you can >>>>>> trigger EINTR when getrandom is stuck). >>>>> >>>>> That only pushes the question back a level. When would it ever be >>>>> necessary to do that? Be as concrete as you possibly can. Actual >>>>> code from a real program, if possible. >>>> >>>> It's not clear to me what you are asking here. >>>> >>>> Do you mean cancellation in general, or cancellation in conjunction with >>>> getrandom specifically? >>> >>> Sorry. I meant cancellation specifically of a thread hanging in >>> getrandom. >> >> I'm not sure how I can provide that, considering that there is currently >> no way to cancel a thread which hangs in getrandom because we do not >> provide a way for applications to implement system calls as cancellation >> points (unless we provide a wrapper for the specific system call, of >> course). > > What I'm asking for is evidence that that is actually a problem for at > least one real application. I found this: ipsec_resolver_thread reads from /dev/random, which can block for a very long time. The thread for it is spawned in ipsec_process_prefs, which cancels it when got_terminate returns true. The intent seems to be that is terminated on graceful process termination: read in ipsec_process_prefs returns EINTR after a signal handler has run which makes got_terminate (defined in main.c in the parent directory) return true. If the read from /dev/random is replaced with a call to getrandom which is not a cancellation point, this would like not work as intended. Is this the kind of stuff you are looking for? > Also evidence that making getrandom a > cancellation point _won't_ break programs that naively assume it can > never fail. Cancellation does not add additional error return cases. Thanks, Florian