From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4A79D5ED6 for ; Wed, 2 Mar 2022 20:07:06 +0000 (UTC) Received: by mail-pj1-f52.google.com with SMTP id em10-20020a17090b014a00b001bc3071f921so5740649pjb.5 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=y3Z971Vd8zlv+WwRo6jFZl34+CvDLOadQG7oPm7RPQGH1gijgwW8n/dRwhVQCfMsTx 3PwKLJ87FEXcDtWotB8BQWyDD8kdIe9Dn/+RIsMKvQ0OLb0iE2W6DGZ0nHw0GYrOd3l5 cn6u3baNafVwlB6dgG/rKzhQb5gY9C2qBpPlV0RHfcwaX/8960/3A7xDYadY2UxMdgQj NlqCplGvYwxvfhGpUEYAw1J/A4n018JzHIbPHCBu3VhJR2t1ZrSvq6tSigvkimHu7gyj P7cMTgYzu1L84CIvg8e+GDMoiF7Lt2M/J/JFkFtHaYryOgVWSbBNVn/FU7fH7GleGDCm Ydrg== X-Gm-Message-State: AOAM53231tz9+9poT+hV/0GgG7ZklL0kc5Ziw9npMzWO9rMG7xVLLiiQ S5/YpbJ083+MNJEuZPymDEjEQg== 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 Cc: Linus Torvalds , David Laight , James Bottomley , linux-wireless , "alsa-devel@alsa-project.org" , KVM list , "Gustavo A. R. Silva" , "linux-iio@vger.kernel.org" , "nouveau@lists.freedesktop.org" , dri-devel , Cristiano Giuffrida , "Bos, H.J." , "linux1394-devel@lists.sourceforge.net" , "drbd-dev@lists.linbit.com" , linux-arch , CIFS , "linux-aspeed@lists.ozlabs.org" , 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 , Brian Johannesmeyer , Nathan Chancellor , dma , 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" , "samba-technical@lists.samba.org" , Linux Kernel Mailing List , Linux F2FS Dev Mailing List , "tipc-discussion@lists.sourceforge.net" , Linux Crypto Mailing List , linux-fsdevel , "linux-mediatek@lists.infradead.org" , Andrew Morton , linuxppc-dev , Christian =?iso-8859-1?Q?K=F6nig?= , Mike Rapoport Subject: Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr 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> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78ccb184-405e-da93-1e02-078f90d2b9bc@rasmusvillemoes.dk> 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 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (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 32069C433EF for ; Wed, 2 Mar 2022 20:07:16 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.94.2) (envelope-from ) id 1nPVFj-0005Dl-My; Wed, 02 Mar 2022 20:07:14 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nPVFi-0005Df-Lo for linux-f2fs-devel@lists.sourceforge.net; Wed, 02 Mar 2022 20:07:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=9llME+iRL2iH9L07jwvbWbmbHLr47Rbz7WJ4fOgTlZc=; b=b4O44c9MiuSSztOYMj8OZkmeek qAfDx2sdZOgazIFZ2EPy2j7wwdKlWlmbI5wvnNMjCN3tVPkH2tsoznvhQHTLe8zMde3vPRDPlSmT/ K+js2eFphiXOWV4iB7CTRr+daSddL49HS9jQ0qAPozeKmRMbG28ZbfXdWDSRoY1e058g=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=9llME+iRL2iH9L07jwvbWbmbHLr47Rbz7WJ4fOgTlZc=; b=gPXPnGXO34/C7n2L1+1rSJd6lJ l1r2gS41ekN3pTU2Aq0ofbPJlKMIDq284rGS70MdXf50GpOkRWfVfVVPrTESOieVAi130qf24uNkC gqM3VMIjtR0cd01sdyHXcOA1IkBKiY618jTKEayXjl5IHJnwGjcD5nOkn4eqXc5/mVv0=; Received: from mail-pl1-f173.google.com ([209.85.214.173]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.94.2) id 1nPVFf-0003CX-Cl for linux-f2fs-devel@lists.sourceforge.net; Wed, 02 Mar 2022 20:07:13 +0000 Received: by mail-pl1-f173.google.com with SMTP id p17so2517369plo.9 for ; Wed, 02 Mar 2022 12:07:11 -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=PwVR1B9ID1+X200IXuk7mQbpVI/6bFoNYi7NFl+/XAZb3Sd8Gk//CSa9dzjHNR7OjF EwIR6hMk98mkQ5hUIQ1isNZ6uw7he1Sd0crzb7rfjY12bCsmviQ+5brX55KaRX7r8sME 0dkZXoI7KHwKmCK9Ajs508pfFEAbK6wBeQ3HUcGPtiHV8UtN9s/OVfjbkOcNCGmQb/VU WBYW5POEl8zqIVoGozLDkOy8gb0iB5K3TuLJ93X7DBJUj3LSeZvwpmNdBfZ3wlrKXDWi dL4c2gUzpiFehBiFkiSyU+bcwewUbjRpSh2zVix62YbfP2wVQ+L+bDonC5LN7ep8gUJX m5BQ== X-Gm-Message-State: AOAM5328n+PY/IQ1l0jee6qQVOvhpn7dkNJxw9DDSOMCfafq5gD+rNq1 9o82QEneOOjCBy7SlphDhPh+cQ== 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-Disposition: inline In-Reply-To: <78ccb184-405e-da93-1e02-078f90d2b9bc@rasmusvillemoes.dk> X-Headers-End: 1nPVFf-0003CX-Cl Subject: Re: [f2fs-dev] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net 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 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 69E09C43219 for ; Wed, 2 Mar 2022 20:07:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HupvV0t34u8tsEMTSleZUvdhAYtNpJNArdP85slHupw=; b=z/DLG82qf1uGeu /yc2wdKPczxzxmdw+Tmjz52fqV6ZDj36xdFSpNvR3866JPZhRNU5TRZuQbYZGL86QE0U2q3jApTYf NfgWivJSzMc0TRQXkRUvuPPAqOQYgMNmQpL7uDMwDz6tVxpJhN3HqXpuXTjrsqBzow+WzYMDzMtU0 zXPf4ltDQ2Cr6p4DwKJ+ZGWFU40GGDonxwxDRWF/DP8ZhPFVaKJXuLukN8MFtI6/8jdN6aDYw+sWw G2wyw6K3Hrm3YcUZIr9OK7S0NRkw5/StHtmU1Pt4LMFA6krZWQf/oj7HdOAQm72mZOIxm+bYZy/b3 SBJ71LvoKv1zWc4JmNbQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPVFf-0043fX-Ft; Wed, 02 Mar 2022 20:07:11 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPVFa-0043eL-HW for linux-mediatek@lists.infradead.org; Wed, 02 Mar 2022 20:07:09 +0000 Received: by mail-pj1-x102b.google.com with SMTP id mg21-20020a17090b371500b001bef9e4657cso2394863pjb.0 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=sG8hLOidaoiOa1k7ezp2X1CKzwM3uPECc1hRQ3lBeCNAnWYFpsL7YRevf4Oeo2QgqG UwlS1TZ953cX+sVoEAV/DYmeRk1M9i/3mD9TgNcBONF/VoafqqsOUXShfsloVzXvlwqz YTsfKa7EjVRq3+RDjs1UB+6dBMge63+0O04UbQD1ORVBb8WDxEUH+5qG6opvjFVbHXxz WJ9lTO8Y2IunhTlxO2FXvF1yOm8plMQCQP17x27qpEtIUidGz4ddLXWw0n7jdfWu2hj+ 6Cz97Ier87rx46h965geZMUaQXjyvqHi/2/ZJJnYlgiexNrFfRPoY9Liutw3+0jx2fjz 7bfQ== X-Gm-Message-State: AOAM531HAfMpj3O8EGEcqKJEhY/fsa8698GOyAaB3bq9iDss2sStLiNj Tax1g5Avym7YYUpycy8yJ0/vvA== 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 Cc: Linus Torvalds , David Laight , James Bottomley , linux-wireless , "alsa-devel@alsa-project.org" , KVM list , "Gustavo A. R. Silva" , "linux-iio@vger.kernel.org" , "nouveau@lists.freedesktop.org" , dri-devel , Cristiano Giuffrida , "Bos, H.J." , "linux1394-devel@lists.sourceforge.net" , "drbd-dev@lists.linbit.com" , linux-arch , CIFS , "linux-aspeed@lists.ozlabs.org" , 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 , Brian Johannesmeyer , Nathan Chancellor , dma , 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" , "samba-technical@lists.samba.org" , Linux Kernel Mailing List , Linux F2FS Dev Mailing List , "tipc-discussion@lists.sourceforge.net" , Linux Crypto Mailing List , linux-fsdevel , "linux-mediatek@lists.infradead.org" , Andrew Morton , linuxppc-dev , Christian =?iso-8859-1?Q?K=F6nig?= , Mike Rapoport Subject: Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr 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-Disposition: inline In-Reply-To: <78ccb184-405e-da93-1e02-078f90d2b9bc@rasmusvillemoes.dk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220302_120706_626505_F106CF62 X-CRM114-Status: GOOD ( 22.15 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (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 C340AC433F5 for ; Thu, 3 Mar 2022 07:06:18 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 18614E0E; Thu, 3 Mar 2022 08:05:27 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 18614E0E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1646291177; bh=nYoSV1UX79csw6ZlcPjNL0QK1+lOw9OPIB7pocuMUUo=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=QViaofi77wGpbmLGOCSFp/JVgpAm9p7mpZ5Xb4CVptY4H56fgyR+oGuMLTHkMXM/E dbZkpmbotw6cHivRA5/m6YEzNNFn7mPMOzbEmyxMlB0pYgMpoQ+H2QQSAeGfiAsRzA EcUqSHgswGxP0idvJeWNMqRRiSLiw+ht7sjDpVEQ= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id ADEA3F80527; Thu, 3 Mar 2022 08:03:31 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 0A392F801D5; Wed, 2 Mar 2022 21:07:11 +0100 (CET) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 51225F80154 for ; Wed, 2 Mar 2022 21:07:08 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 51225F80154 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="IvpJRwG7" Received: by mail-pj1-x1031.google.com with SMTP id 15-20020a17090a098f00b001bef0376d5cso2798379pjo.5 for ; Wed, 02 Mar 2022 12:07:07 -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=JquopSzbcThtrDOU3KGEdf1qpky3832cUd73ezJ4xTkJdvD31aNEnO1o9Ykcd1Xvw1 h4eRzaJi+m+7xkHNyUTQwuLq795upVr4VuZOslNzPxnYniCQDO+JwUrsHpVwvq3aequ4 /r/2qiiDGvCKAEGpU+98hrKPxcBosnbPSu75Va9+RchIi1ehfiRJoKpPf6d8G9LSoXtp fWzUrlMBZNr3czs9IiAULrMD2K9hIJElYtOLh4+dLSem01NCGRJWCzQyRDKqhuRRtvcM EOlfVkhKAVIbnXvlH92sZRnytCTRtZBY30YUKu+flrz1qSof4BBAwWTmj//RgnDKYb/R mlAw== X-Gm-Message-State: AOAM532y/l/eguD1GN+rs2iZFi/ScZ3cW/ZrxQD2+DPvUNhAGGTjAZGl Dbe7UDYWddzFsHbS0fO/BkSozg== 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 Subject: Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr 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> X-Mailman-Approved-At: Thu, 03 Mar 2022 08:03:24 +0100 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 X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" 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 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 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 42542C433FE for ; Tue, 8 Mar 2022 04:27:49 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A444A10E6AC; Tue, 8 Mar 2022 04:27:30 +0000 (UTC) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by gabe.freedesktop.org (Postfix) with ESMTPS id 331C910E25B for ; Wed, 2 Mar 2022 20:07:06 +0000 (UTC) Received: by mail-pl1-x631.google.com with SMTP id bd1so2501915plb.13 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=jbxVxi0l2B3HDfY1u1/Pjs6+g4UEo9Q8UpcHsGxmGkJwZzuE9Uxb07qU6Xi6vbET7l q92lU01gxFQ+dTOS0obFDtluk8B1NOf4S38kVXyP5qxK0gpZTY3xUrX9vH2TiGw8pTjG EZCKVroAp39dsT7YbzJ+uTCyO2ML7i5xUjt07tQ9D0TY1wMzNn8hdl/en7N3V/NPSITx bLeTKNMLBrsWuFdlV/eu639nqb1RzS5saJr/hVfIwB8GImvakeJlWgUaKuHVkagDToq1 QPP3UNgMaS9gyxCMMMWqayZLdAGecug+gKxQ0NzTXUyf2lTNU5GQYRajtx+zjze4gLI3 mbyw== X-Gm-Message-State: AOAM530/GDBjI1QGmivFemY1CaFXf9ZxFRNRyDK8xfzN4I0729S7Z+Ht LAgQCAvcLvIMwNH4WrZKz3jojA== 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> X-Mailman-Approved-At: Tue, 08 Mar 2022 04:27:27 +0000 Subject: Re: [Nouveau] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list 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: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Date: Wed, 2 Mar 2022 12:07:04 -0800 Subject: [Intel-wired-lan] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr In-Reply-To: <78ccb184-405e-da93-1e02-078f90d2b9bc@rasmusvillemoes.dk> 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> Message-ID: <202203021158.DB5204A0@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: 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