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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2304BC433EF for ; Wed, 2 Mar 2022 20:07:08 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8D40A10E25B; Wed, 2 Mar 2022 20:07:07 +0000 (UTC) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3C80410E4FC for ; Wed, 2 Mar 2022 20:07:06 +0000 (UTC) Received: by mail-pl1-x62b.google.com with SMTP id n15so2532902plf.4 for ; Wed, 02 Mar 2022 12:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=9llME+iRL2iH9L07jwvbWbmbHLr47Rbz7WJ4fOgTlZc=; b=IvpJRwG7ynxkReEE85KaN5rJUYtD4xKNHA+hy6TwBmoQ8B3uYeJI+QViQcnaGiWq86 F88M3HTERkoil1v4VBpPtCvYuei+/tfueI2kCXzM7ddvcotxLyWZwiewhTHLUCy28lRK BraqPBOXvwYRthhpbxTgJWS9pGCc3zSZJBqHk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9llME+iRL2iH9L07jwvbWbmbHLr47Rbz7WJ4fOgTlZc=; b=w1XIsgioq+mYE/pxyOthGxF7juY9dfoGTxmQnSl/A0bvEF3GbAcegShiedp+4xxixX u2MSEA836t/qlQXDUWAS+bpwA9knbqn04TKtiFL+O6uMQ3XCTHF6T4Cwi4D3LeYsf0Ct I9NlSxS3wvD+3aqw8x32CATZjNlZlQcnNAzp6HNyMaDvDqltP7Mf+Iy2UMg/gy2+AEHG b6fyIiMGaFj2inKynNtDvVhNorv316XEOs9vS/SAs4xu4+m7GY28BrgklJR+EMPIOi7p b3UxEGspThV+dZET6KucDeuBUzkMVJPJSLdQvmfm1MDPw0/2wwqPfXp1oMPsSWfxHMyc Id+Q== X-Gm-Message-State: AOAM532aPEzxhn+bw79aSRQ5OnIqtIrGVgRrO9s6rD0v7CmzzMp9ZafE 1YLCiD+hRCgWQDl8B7921yK+UA== X-Google-Smtp-Source: ABdhPJyalZw/yElDAQSdRYusWOxjkvZUrvn+e5j/jboS/+hXUtUpvVb6mMnbBbqlv1j/a0ygzQBPkQ== X-Received: by 2002:a17:90b:94e:b0:1bc:c99f:ede1 with SMTP id dw14-20020a17090b094e00b001bcc99fede1mr1518926pjb.49.1646251625762; Wed, 02 Mar 2022 12:07:05 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id d25-20020a637359000000b0037843afb785sm6664pgn.25.2022.03.02.12.07.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 12:07:05 -0800 (PST) Date: Wed, 2 Mar 2022 12:07:04 -0800 From: Kees Cook To: Rasmus Villemoes Message-ID: <202203021158.DB5204A0@keescook> References: <282f0f8d-f491-26fc-6ae0-604b367a5a1a@amd.com> <7D0C2A5D-500E-4F38-AD0C-A76E132A390E@kernel.org> <73fa82a20910c06784be2352a655acc59e9942ea.camel@HansenPartnership.com> <7dc860874d434d2288f36730d8ea3312@AcuMS.aculab.com> <0ced2b155b984882b39e895f0211037c@AcuMS.aculab.com> <78ccb184-405e-da93-1e02-078f90d2b9bc@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78ccb184-405e-da93-1e02-078f90d2b9bc@rasmusvillemoes.dk> Subject: Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "alsa-devel@alsa-project.org" , "linux-aspeed@lists.ozlabs.org" , "Gustavo A. R. Silva" , "linux-iio@vger.kernel.org" , "nouveau@lists.freedesktop.org" , dri-devel , James Bottomley , Cristiano Giuffrida , "Bos, H.J." , "samba-technical@lists.samba.org" , "linux1394-devel@lists.sourceforge.net" , "drbd-dev@lists.linbit.com" , linux-arch , CIFS , KVM list , linux-scsi , linux-rdma , "linux-staging@lists.linux.dev" , amd-gfx list , Jason Gunthorpe , "intel-wired-lan@lists.osuosl.org" , "kgdb-bugreport@lists.sourceforge.net" , "bcm-kernel-feedback-list@broadcom.com" , Dan Carpenter , Linux Media Mailing List , Arnd Bergman , Linux PM , intel-gfx , linuxppc-dev , Brian Johannesmeyer , Nathan Chancellor , linux-fsdevel , Christophe JAILLET , Jakob Koschel , "v9fs-developer@lists.sourceforge.net" , linux-tegra , Thomas Gleixner , Andy Shevchenko , Linux ARM , "linux-sgx@vger.kernel.org" , linux-block , Netdev , "linux-usb@vger.kernel.org" , linux-wireless , Linux Kernel Mailing List , Linux F2FS Dev Mailing List , David Laight , "tipc-discussion@lists.sourceforge.net" , Linux Crypto Mailing List , dma , "linux-mediatek@lists.infradead.org" , Andrew Morton , Linus Torvalds , Christian =?iso-8859-1?Q?K=F6nig?= , Mike Rapoport Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, Mar 02, 2022 at 10:29:31AM +0100, Rasmus Villemoes wrote: > This won't help the current issue (because it doesn't exist and might > never), but just in case some compiler people are listening, I'd like to > have some sort of way to tell the compiler "treat this variable as > uninitialized from here on". So one could do > > #define kfree(p) do { __kfree(p); __magic_uninit(p); } while (0) > > with __magic_uninit being a magic no-op that doesn't affect the > semantics of the code, but could be used by the compiler's "[is/may be] > used uninitialized" machinery to flag e.g. double frees on some odd > error path etc. It would probably only work for local automatic > variables, but it should be possible to just ignore the hint if p is > some expression like foo->bar or has side effects. If we had that, the > end-of-loop test could include that to "uninitialize" the iterator. I've long wanted to change kfree() to explicitly set pointers to NULL on free. https://github.com/KSPP/linux/issues/87 The thing stopping a trivial transformation of kfree() is: kfree(get_some_pointer()); I would argue, though, that the above is poor form: the thing holding the pointer should be the thing freeing it, so these cases should be refactored and kfree() could do the NULLing by default. Quoting myself in the above issue: Without doing massive tree-wide changes, I think we need compiler support. If we had something like __builtin_is_lvalue(), we could distinguish function returns from lvalues. For example, right now a common case are things like: kfree(get_some_ptr()); But if we could at least gain coverage of the lvalue cases, and detect them statically at compile-time, we could do: #define __kfree_and_null(x) do { __kfree(*x); *x = NULL; } while (0) #define kfree(x) __builtin_choose_expr(__builtin_is_lvalue(x), __kfree_and_null(&(x)), __kfree(x)) Alternatively, we could do a tree-wide change of the former case (findable with Coccinelle) and change them into something like kfree_no_null() and redefine kfree() itself: #define kfree_no_null(x) do { void *__ptr = (x); __kfree(__ptr); } while (0) #define kfree(x) do { __kfree(x); x = NULL; } while (0) -- Kees Cook