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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 AAF75C433B4 for ; Wed, 19 May 2021 15:28:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2701C611B0 for ; Wed, 19 May 2021 15:28:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2701C611B0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7C4796B0036; Wed, 19 May 2021 11:28:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 79AFB6B006E; Wed, 19 May 2021 11:28:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6149E6B0070; Wed, 19 May 2021 11:28:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0122.hostedemail.com [216.40.44.122]) by kanga.kvack.org (Postfix) with ESMTP id 2DD106B0036 for ; Wed, 19 May 2021 11:28:17 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C7EE38249980 for ; Wed, 19 May 2021 15:28:16 +0000 (UTC) X-FDA: 78158361792.13.1E2A89A Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf18.hostedemail.com (Postfix) with ESMTP id B307E20007F0 for ; Wed, 19 May 2021 15:28:15 +0000 (UTC) Received: by mail-qt1-f172.google.com with SMTP id k19so10410916qta.2 for ; Wed, 19 May 2021 08:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=t+Qf8jBffPJDUSlKRZVMI8zX4NSNOwtmPk0wyLsEYn4=; b=gxC+ShG+NpGHpTZL/MrzZTdrhoD98Dy7r+epu3GJOUGxy8HV2fUwvcbqrl4NwH9UMm LIEXDLzwm03nY0X9S3fn74RbkPPpQfNmnO/xDritCY5hJRTjU37cs3HZ9fzsi2QjEwOM v2w0fhhEDhvykuV97BBVUPps+dHVyv/woHKaGJ57JO9axQK4Y9Exka7tvt4u2O5uN/RT f9W8WQe3fJvv8PJngNvbGTZxCdFfiKg/X7sGG+0QIjNyl83PPNHLMK8aguCjZ7RZYiPR 02n0r4AHmmYpm33dBuSrBs0n77eEEkTGxUsaVawtEfuM9m5RkOSPDLhUMHkXLnN7+R9Z zWig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=t+Qf8jBffPJDUSlKRZVMI8zX4NSNOwtmPk0wyLsEYn4=; b=lXksz6tzcfa9VQkNkoPBvfKma8bEglHDh5M0YFgmugzaAaK7lws39kYQRd7pTKklXy xnotx3LUa+tigmCr2vthR25/2zwiktLkbRF4u3mz0zGw3Sasu0Qu5FwOS++fBM9TRViB BzBxOtUjeyjyKBdZ58rBHNVIouJMBurrVZSlXwj48K9AxG0Bkb08ZE8mirRXfzPBlJ8t tseuz6SZRbL6qxX5zJvgJNIFe7NPlPdBrsrCcoOYViTkVe/E9ms3qR7EZO6kqez4djCm l1Ztir4qmIocYIgPglD9lZSTBu+NyoQrD8w+Ns58FOpmUbQ/8v1Yz6bYd4WCqj/j6Q7u tXwA== X-Gm-Message-State: AOAM532OgTwvRQwWCzNlav2260Li3rT8SFcB6/ovEFLLr5JCf1P7ZXpb 9xeMSFLg28SfOSKT3m6JLUQ= X-Google-Smtp-Source: ABdhPJxp9sbb8rs6CsjQCKcMq6IeId9cBid9WMvSf6pGtqtW66sTZFk0wWLorHY0bYP/AqF9OHLdzg== X-Received: by 2002:a05:622a:392:: with SMTP id j18mr259202qtx.29.1621438095831; Wed, 19 May 2021 08:28:15 -0700 (PDT) Received: from localhost ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id 64sm2207536qtc.95.2021.05.19.08.28.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 May 2021 08:28:14 -0700 (PDT) Date: Wed, 19 May 2021 08:28:12 -0700 From: Guenter Roeck To: Segher Boessenkool Cc: Michael Ellerman , "Aneesh Kumar K.V" , npiggin@gmail.com, linux-mm@kvack.org, kaleshsingh@google.com, joel@joelfernandes.org, akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v5 5/9] powerpc/mm/book3s64: Update tlb flush routines to take a page walk cache flush argument Message-ID: <20210519152812.GA3109563@roeck-us.net> References: <20210515163525.GA1106462@roeck-us.net> <87pmxpqxb1.fsf@linux.ibm.com> <87a6ork1qp.fsf@mpe.ellerman.id.au> <20210519004514.GC10366@gate.crashing.org> <20210519120306.GD10366@gate.crashing.org> <46cedc01-bca7-236d-9f74-a9cc24391512@roeck-us.net> <20210519142038.GI10366@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210519142038.GI10366@gate.crashing.org> Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=gxC+ShG+; dmarc=none; spf=pass (imf18.hostedemail.com: domain of groeck7@gmail.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=groeck7@gmail.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B307E20007F0 X-Stat-Signature: o7yesyux7y4y8tm64tuqkc96bo4oqzoc X-HE-Tag: 1621438095-792546 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, May 19, 2021 at 09:20:38AM -0500, Segher Boessenkool wrote: > On Wed, May 19, 2021 at 06:37:44AM -0700, Guenter Roeck wrote: > > On 5/19/21 5:03 AM, Segher Boessenkool wrote: > > >On Tue, May 18, 2021 at 07:45:14PM -0500, Segher Boessenkool wrote: > > >>And it actually explicitly is undefined behaviour in C90 already > > >>(3.6.6.4 in C90, 6.8.6.4 in C99 and later). > > > > > >... but there is a GCC extension that allows this by default: > > > > > > For C only, warn about a 'return' statement with an expression in a > > > function whose return type is 'void', unless the expression type is > > > also 'void'. As a GNU extension, the latter case is accepted > > > without a warning unless '-Wpedantic' is used. > > > > In C99: > > > > "6.8.6.4 The return statement > > Constraints > > > > A return statement with an expression shall not appear in a function whose > > return type > > is void. A return statement without an expression shall only appear in a > > function > > whose return type is void." > > > > Sounds like invalid to me, not just undefined behavior. > > I don't know what "invalid" would mean here other than UB, it isn't a > specific defined term, unlike the latter, which is precisely defined in > 3.4.3/1: > undefined behavior > behavior, upon use of a nonportable or erroneous program construct or > of erroneous data, for which this International Standard imposes no > requirements > > This is the strongest thing the standard can say, it is not Law, it does > not prohibit anyone from doing anything :-) > > "Shall" and "shall not" X means it is undefined behaviour if X (or its > inverse) is violated. See 4.2: > If a ''shall'' or ''shall not'' requirement that appears outside of a > constraint or runtime-constraint is violated, the behavior is > undefined. Undefined behavior is otherwise indicated in this > International Standard by the words ''undefined behavior'' or by the > omission of any explicit definition of behavior. There is no > difference in emphasis among these three; they all describe ''behavior > that is undefined''. > which also explains that what you call "invalid" has undefined behaviour > just as well, most likely. > I'd have assumed that "shall not" is syntactically wrong, but I stand corrected. Guenter 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 7249BC433ED for ; Wed, 19 May 2021 15:28:51 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 ADDB1611AD for ; Wed, 19 May 2021 15:28:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ADDB1611AD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FlcGT1TCGz3077 for ; Thu, 20 May 2021 01:28:49 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=gxC+ShG+; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::82c; helo=mail-qt1-x82c.google.com; envelope-from=groeck7@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=gxC+ShG+; dkim-atps=neutral Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 4FlcFw5ZNFz2xZS for ; Thu, 20 May 2021 01:28:19 +1000 (AEST) Received: by mail-qt1-x82c.google.com with SMTP id v4so10396191qtp.1 for ; Wed, 19 May 2021 08:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=t+Qf8jBffPJDUSlKRZVMI8zX4NSNOwtmPk0wyLsEYn4=; b=gxC+ShG+NpGHpTZL/MrzZTdrhoD98Dy7r+epu3GJOUGxy8HV2fUwvcbqrl4NwH9UMm LIEXDLzwm03nY0X9S3fn74RbkPPpQfNmnO/xDritCY5hJRTjU37cs3HZ9fzsi2QjEwOM v2w0fhhEDhvykuV97BBVUPps+dHVyv/woHKaGJ57JO9axQK4Y9Exka7tvt4u2O5uN/RT f9W8WQe3fJvv8PJngNvbGTZxCdFfiKg/X7sGG+0QIjNyl83PPNHLMK8aguCjZ7RZYiPR 02n0r4AHmmYpm33dBuSrBs0n77eEEkTGxUsaVawtEfuM9m5RkOSPDLhUMHkXLnN7+R9Z zWig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=t+Qf8jBffPJDUSlKRZVMI8zX4NSNOwtmPk0wyLsEYn4=; b=nOzoO36y3CxpSYhPMH0UOwud6J3Ns3Z5XICnrb51zh6rwf4dBFYmlisjH6iOsgmVJq +vasBpKMTT1Z2LYZf5qFDKwdmpct3g5SRRb7OfNIak+3g/jI+LBM9WWEb5fW4GXruDvZ mSA2lJRpruof2CkqSsctI3jZMpCUW+FchZcX6XNQcAeBw35PYNjz6VJlHWP0skV3+sWF vojlz3Cy8Qpt/5MTMCQ5yMy3ZXFFX7iH6NJBskpPlF8EEN8qkVvoDeRUltCN8sRVlQXh oUpT+YYjtw/IuYWTt/+0hJeClMNzt/i+muFeh0O+7NB4UE7bGzPYyZJDBDLoo0YmdaOK BO2w== X-Gm-Message-State: AOAM5318hsJVrAHRi5cXnBoiiPFofuRJME6T15IldFCCcvRxfNwzzHof R5+Y79BFpwroyzOJqS8oLqw= X-Google-Smtp-Source: ABdhPJxp9sbb8rs6CsjQCKcMq6IeId9cBid9WMvSf6pGtqtW66sTZFk0wWLorHY0bYP/AqF9OHLdzg== X-Received: by 2002:a05:622a:392:: with SMTP id j18mr259202qtx.29.1621438095831; Wed, 19 May 2021 08:28:15 -0700 (PDT) Received: from localhost ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id 64sm2207536qtc.95.2021.05.19.08.28.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 May 2021 08:28:14 -0700 (PDT) Date: Wed, 19 May 2021 08:28:12 -0700 From: Guenter Roeck To: Segher Boessenkool Subject: Re: [PATCH v5 5/9] powerpc/mm/book3s64: Update tlb flush routines to take a page walk cache flush argument Message-ID: <20210519152812.GA3109563@roeck-us.net> References: <20210515163525.GA1106462@roeck-us.net> <87pmxpqxb1.fsf@linux.ibm.com> <87a6ork1qp.fsf@mpe.ellerman.id.au> <20210519004514.GC10366@gate.crashing.org> <20210519120306.GD10366@gate.crashing.org> <46cedc01-bca7-236d-9f74-a9cc24391512@roeck-us.net> <20210519142038.GI10366@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210519142038.GI10366@gate.crashing.org> 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: npiggin@gmail.com, linux-mm@kvack.org, "Aneesh Kumar K.V" , kaleshsingh@google.com, joel@joelfernandes.org, akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, May 19, 2021 at 09:20:38AM -0500, Segher Boessenkool wrote: > On Wed, May 19, 2021 at 06:37:44AM -0700, Guenter Roeck wrote: > > On 5/19/21 5:03 AM, Segher Boessenkool wrote: > > >On Tue, May 18, 2021 at 07:45:14PM -0500, Segher Boessenkool wrote: > > >>And it actually explicitly is undefined behaviour in C90 already > > >>(3.6.6.4 in C90, 6.8.6.4 in C99 and later). > > > > > >... but there is a GCC extension that allows this by default: > > > > > > For C only, warn about a 'return' statement with an expression in a > > > function whose return type is 'void', unless the expression type is > > > also 'void'. As a GNU extension, the latter case is accepted > > > without a warning unless '-Wpedantic' is used. > > > > In C99: > > > > "6.8.6.4 The return statement > > Constraints > > > > A return statement with an expression shall not appear in a function whose > > return type > > is void. A return statement without an expression shall only appear in a > > function > > whose return type is void." > > > > Sounds like invalid to me, not just undefined behavior. > > I don't know what "invalid" would mean here other than UB, it isn't a > specific defined term, unlike the latter, which is precisely defined in > 3.4.3/1: > undefined behavior > behavior, upon use of a nonportable or erroneous program construct or > of erroneous data, for which this International Standard imposes no > requirements > > This is the strongest thing the standard can say, it is not Law, it does > not prohibit anyone from doing anything :-) > > "Shall" and "shall not" X means it is undefined behaviour if X (or its > inverse) is violated. See 4.2: > If a ''shall'' or ''shall not'' requirement that appears outside of a > constraint or runtime-constraint is violated, the behavior is > undefined. Undefined behavior is otherwise indicated in this > International Standard by the words ''undefined behavior'' or by the > omission of any explicit definition of behavior. There is no > difference in emphasis among these three; they all describe ''behavior > that is undefined''. > which also explains that what you call "invalid" has undefined behaviour > just as well, most likely. > I'd have assumed that "shall not" is syntactically wrong, but I stand corrected. Guenter