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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 D1EDBC4320A for ; Tue, 27 Jul 2021 10:19:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B66F661529 for ; Tue, 27 Jul 2021 10:19:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236205AbhG0KTi (ORCPT ); Tue, 27 Jul 2021 06:19:38 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:54981 "EHLO wout5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236131AbhG0KTg (ORCPT ); Tue, 27 Jul 2021 06:19:36 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 063C93200910; Tue, 27 Jul 2021 06:19:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 27 Jul 2021 06:19:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-id:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=QmLMBA6Xti0HU0XKBmTE0w8Hds9Nrr+uYvql2a6fe88=; b=QxRjhR41 g4n0z4jYVLmHonJgX3FNAJaMIEF/NoXCx1TlH2QsMb02JXL0ezFhzjmk39nDOQ1h VQ+ZReEi0jbBoxB5i3I4C68X0k66e3A/wfCWZcUeQ7OkT+lnoadN8++d3Qy7TDmE FYHD+jXQykY0fMU2PIZAAPXs48WmG2vo0L6XqCyGxY+CPgN/4ym+DE7+tpjNcrNw wU6aCNs2IJ9c1Ol5UiiKURuCHO1O8p6aVGIlyZFv+tamoXX4kCOoYGuFDeS5z/Ic Kjd5PVxfVdWbIps3VRPyirHZQOUbHztBt0s29j8ryluUd/5vTFrt8II1aht5bd8B e2AWboh90cOVAg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeejgddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvufgjkfhfgggtsehmtderredttdejnecuhfhrohhmpefhihhnnhcuvfhh rghinhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrghtth gvrhhnpeefffejiefgheevheefvefhteeggfeijeeiveeihfffffdugfefkeelfffhgfeh vdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfth hhrghinheslhhinhhugidqmheikehkrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 27 Jul 2021 06:19:32 -0400 (EDT) Date: Tue, 27 Jul 2021 20:19:35 +1000 (AEST) From: Finn Thain To: Geert Uytterhoeven cc: =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Greg Kroah-Hartman , Linux Kernel Mailing List , Sascha Hauer , linux-m68k Subject: Re: [PATCH 1/5] nubus: Simplify check in remove callback In-Reply-To: Message-ID: <194b351c-bae-27a-1875-9ad3c47292e@linux-m68k.org> References: <20210727080840.3550927-1-u.kleine-koenig@pengutronix.de> <20210727080840.3550927-2-u.kleine-koenig@pengutronix.de> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1463811774-894125592-1627380959=:28" Content-ID: <4a49a1b2-e172-446c-be33-62c34c8bdc97@nippy.intranet> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463811774-894125592-1627380959=:28 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Tue, 27 Jul 2021, Geert Uytterhoeven wrote: > On Tue, Jul 27, 2021 at 11:50 AM Finn Thain wrote= : > > On Tue, 27 Jul 2021, Uwe Kleine-K=C3=B6nig wrote: > > > Apart from that, the compiler might already assume dev->driver being= =20 > > > non-NULL after to_nubus_driver(dev->driver) was called. > > > > I don't understand how a compiler can make that assumption. But then,= =20 > > I don't know why compilers do a lot of the things they do... >=20 > It is one of those recent optimizations people have been complaining=20 > about. Once you have dereferenced a pointer, compilers may remove all=20 > further NULL-checks, assuming they can't happen, as the code would have= =20 > crashed anyway before due to the dereference. But that's the point -- there is no dereference, just pointer arithmetic. > Good luck running on bare metal with RAM at zero ;-) Quite. ---1463811774-894125592-1627380959=:28--