Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp3182548rwb; Sat, 12 Nov 2022 00:20:18 -0800 (PST) X-Google-Smtp-Source: AA0mqf6dMAdKvlZCIUo30xe7phDmGoNQK5jOTXy5+Su98LUzoNu8Act20m0Y6O48VvQCw7PcpqQ9 X-Received: by 2002:aa7:d697:0:b0:461:dbcc:5176 with SMTP id d23-20020aa7d697000000b00461dbcc5176mr4635047edr.53.1668241218189; Sat, 12 Nov 2022 00:20:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668241218; cv=none; d=google.com; s=arc-20160816; b=rihxmwhzCZiC9resFJ6Rt38QxL22uvUL0cchMNojorFPROkZ6IbG0hoOyonTz2VRiX N9eLYcTcFbhy3IoPLZYOWD0gTVPwu1YkAS7WQBLgIz8ZdX2tzH7yCDTmWu9P5p9lFc8r KIcAxM+guZhgCElMIBhAPi3fRd5IDTEj6uPAx7zMjuRt4U/LbCdu+jj7Qj+clovs9K0F IIdFKOy6j8IqRtr/MDaduNuHGEJUxGIl56F93/pNKA32xIW0g8PTP6zRMh6Wsg6HdusE R05rGnauxxnqNRg67gsVQ17CB4o8Ol3MHJuj7zzFK+4SihsLUc8jsFJS9MAEQeU6DT98 tnhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=gQvpmQTgyroDLhRcK9y34ohu3wGYHPKZJd+EgQ4Xqdg=; b=JVAL7OTBl3V37pBlHa649FkEPiDeZMcMQ1TfxjZdlMBgbwKBcq2zLkuDjOamws8fxV st3JoowgIr/6K56EgND1oN+T06UQNyWg0IdBvC10SF4gmUgP28Y8FPD9tb8ITwNw9FNo LFs33hnHDeysCSTX6pwahftAmthbIxFOfoalNuTp44DdWpf6HcTjxL4X+UI8jdNenM4C iImJWBIYlWxxiJgiRJTpSTLiyW7Pvazvzt6HVgiGOO/Sq9ACe2iUXilpbLllh4/4kl8h frAddnSZ1CZYqzHxHULntIFlzX4eX1AXHknJ0qo1srvjGm28jVtiLHdGCYnNVcGouneI 55+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s10-20020aa7d78a000000b004617f587912si4024905edq.279.2022.11.12.00.19.56; Sat, 12 Nov 2022 00:20:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234540AbiKLHsG (ORCPT + 90 others); Sat, 12 Nov 2022 02:48:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59630 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234312AbiKLHsE (ORCPT ); Sat, 12 Nov 2022 02:48:04 -0500 Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A3B8710C6 for ; Fri, 11 Nov 2022 23:48:02 -0800 (PST) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 2AC7lxuu005221; Sat, 12 Nov 2022 08:47:59 +0100 Date: Sat, 12 Nov 2022 08:47:59 +0100 From: Willy Tarreau To: A Cc: linux-kernel@vger.kernel.org Subject: Re: Setting variable NULL after freeing it. Message-ID: <20221112074759.GA5111@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 12, 2022 at 11:47:39AM +0530, A wrote: > Hi, > > I am writing a linux kernel driver for a new device. > > Is it a good practice to set variable NULL after freeing it? > > Something like this - > > kfree(x); > x = NULL; > > Please let me know. It depends. What's important is not to let a pointer exist to a freed location, so if you're doing: kfree(card->pool); then it's usually important to follow this by: card->pool = NULL; so that no code stumbles upon that rotten pointer. Similarly if you're freeing a variable in the middle of a function or inside an "if" block, it's wise to reset the pointer so that it doesn't continue to exist further in the function, and is visually easier to track for anyone reviewing that code. But a lot of kfree() calls exist in return paths and are only followed by other kfree() and a return statement. In this case, it can be completely useless to NULL a local variable that was just freed as the variable stops existing when returning. For example, below nullifying the pointers wouldn't bring anything: kfree(card->pool); kfree(card); return -EBUSY; A good way to check common practices is to check with git grep how current code already deals with this: $ git grep -wA3 kfree You'll notice that all practices indeed exist. Willy PS: you could more easily get responses in the future by associating a real name with your address instead of just "A" which makes it look like a spam.