From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1AD75CA9EAD for ; Sun, 20 Oct 2019 19:55:19 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8A29A21928 for ; Sun, 20 Oct 2019 19:55:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8A29A21928 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46x9VD2kvqzDqRR for ; Mon, 21 Oct 2019 06:55:16 +1100 (AEDT) Received: from ozlabs.org (bilbo.ozlabs.org [IPv6:2401:3900:2:1::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46x9SF5drvzDqNK for ; Mon, 21 Oct 2019 06:53:33 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linutronix.de Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) by bilbo.ozlabs.org (Postfix) with ESMTP id 46x9SF4fXTz8tT3 for ; Mon, 21 Oct 2019 06:53:33 +1100 (AEDT) Received: by ozlabs.org (Postfix) id 46x9SF4F3Nz9sNx; Mon, 21 Oct 2019 06:53:33 +1100 (AEDT) Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linutronix.de (client-ip=2a0a:51c0:0:12e:550::1; helo=galois.linutronix.de; envelope-from=tglx@linutronix.de; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linutronix.de Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46x9SD3RQmz9sNw for ; Mon, 21 Oct 2019 06:53:31 +1100 (AEDT) Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iMHGS-0003oc-L8; Sun, 20 Oct 2019 21:53:20 +0200 Date: Sun, 20 Oct 2019 21:53:19 +0200 (CEST) From: Thomas Gleixner To: Andreas Schwab Subject: Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11 In-Reply-To: <87r237h01a.fsf@igel.home> Message-ID: References: <0fc22a08-31d9-e4d1-557e-bf5b482a9a20__6444.28012180782$1571503753$gmane$org@c-s.fr> <87v9skcznp.fsf@igel.home> <87tv83zqt1.fsf@hase.home> <875zkjipra.fsf@igel.home> <87r237h01a.fsf@igel.home> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nathan Lynch , Vincenzo Frascino , "linuxppc-dev@ozlabs.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Sun, 20 Oct 2019, Andreas Schwab wrote: > On Okt 20 2019, Thomas Gleixner wrote: > > > POSIX does not mention anything about the validity of the pointer handed to > > clock_getres(). > > Sure it does: "If the argument res is not NULL, the resolution of the > specified clock shall be stored in the location pointed to by res. If > res is NULL, the clock resolution is not returned.". Sigh, that makes a lot of sense - NOT. But for the sake of making a non-sensical specification happy we can add a NULL pointer check for this. The interesting question is what should be returned in this case. The kernel returns EFAULT which is probably not POSIX compliant either. Patches are welcome. Thanks, tglx