From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80659 invoked by alias); 16 Nov 2016 19:53:00 -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 79957 invoked by uid 89); 16 Nov 2016 19:52:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2341, riegel, torvald, Riegel X-HELO: mail-ua0-f180.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=M+CgO8ZceRY9AHifka12OjhOa5cgsNgvYyjCj4Spalk=; b=KxMMXpdsdWC90/aIYRAYiey3Z2KJP3bMSYKPsF245XTE4e+wrHJsPSrJsBPRpgbqPJ sYtvtQMD+vcUvrHCT+Qqfj+zm6B4aLWQz7Dl7wsVOSqrJf7JZJJT2Nr6lHqo/NvFlk1K tLxqWLtV6THbAvu39h8Ch1rH0BMwJ7iyPhp/0gZuWRrcXWQxzAhiMxo93sm7SnbBPwjP RJv9IF0sKi39NblwKBP6Q+z6RmjYnJfEXrOlTxnEmidGRQT5XGYFCIpawdMIwklY0Bbf BzMt5NnaVoK0qHSy7zztwCFG0vvmtwF3v2lU77nMUjZTlBe9gicVdrp+RjrpZNwTjB1N PVWA== X-Gm-Message-State: ABUngvcH5PYfMORt2iM9AfnuAnT8iekcNxrIxZV+mvddfMJPZ9iiqEsQVdM2W9epY0TPdvmy X-Received: by 10.159.35.108 with SMTP id 99mr2803969uae.4.1479325967462; Wed, 16 Nov 2016 11:52:47 -0800 (PST) Subject: Re: [PATCH v7] getrandom system call wrapper [BZ #17252] To: libc-alpha@sourceware.org References: <3dd5d3b8-c196-98fb-1671-90cd90ab90c7@redhat.com> <244f578c-889a-a4cf-c686-bb2a5e49cca1@panix.com> <2d175242-1a82-9410-d01e-682ab4d9081e@panix.com> <1479319342.7146.1143.camel@localhost.localdomain> From: Adhemerval Zanella Message-ID: <950ffaeb-8984-7840-e495-12442f821c9c@linaro.org> Date: Wed, 16 Nov 2016 19:53: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: <1479319342.7146.1143.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-11/txt/msg00593.txt.bz2 On 16/11/2016 16:02, Torvald Riegel wrote: > On Wed, 2016-11-16 at 16:52 +0100, Florian Weimer wrote: >> On 11/16/2016 04:20 PM, Zack Weinberg wrote: >>> On 11/16/2016 10:11 AM, Florian Weimer wrote: >>>> On 11/14/2016 07:29 PM, Zack Weinberg wrote: >>>>> On 11/14/2016 12:44 PM, Florian Weimer wrote: >>>>>> This patch switches back to the ssize_t return time. This goes against >>>>>> Theodore Ts'o preference, but seems to reflect the consensus from the >>>>>> largery community. >>>>> >>>>> I still don't think this function should be a cancellation point. >>>> >>>> I guess we'll have to agree to disagree on this matter. >>> >>> 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). > > I think it would be better to split the getrandom that is a cancellation > point into two functions, getrandom (not a cancellation point) and > getrandom_cancelable (is a cancellation point). This way, the > functionality is available for programs but requires explicit opt-in, > while the default is not going to lead to surprises in the expected > common case (ie, when randomness is available). I don't think the > opt-in is a problem because as you said, cancellation requires careful > programming anyway. > I would advise against adding another symbol, it only adds complexity and most likely one interface would be preferable from application point of view. Considering portability, why not following current approach from other OS/libc? User will probably create more highly level interfaces based underlying facilities, so I see trying to follow current interface semantics in a non standard interface seems a better approach. For instance, OpenBSD getentropy seems a to just direct syscall, so not cancellation handling (src/libexec/ld.so//ldasm.S). FreeBSD does not have a similar syscall, but provides a sysctl/KERN_ARND that does basically the same. I am not sure about Solaris.