Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp6645097rdb; Tue, 2 Jan 2024 08:29:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IFMw8QIWsP1Cxn5Xt8gy1zBBCgKA7t+1DD99ZM2PnFiWwY0P1FUVx7safpqxfjXIHBuip93 X-Received: by 2002:a62:a50b:0:b0:6d9:d5a7:9ca9 with SMTP id v11-20020a62a50b000000b006d9d5a79ca9mr12130098pfm.0.1704212960864; Tue, 02 Jan 2024 08:29:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704212960; cv=none; d=google.com; s=arc-20160816; b=Xud5vUA6x6nz21042mJ642B6WJQkPMOaRR0yWDJbcMA7BzfLmtcWJ5Eo3i0e3VIZ/F 8OBviUWChlVpaRupErkJlBPAss/kfmPC+z7I3YIazqZWj6QHSoL9FRvalvi1x9sB5jeM pL0JDxIox6xHdhR6WZLT4RPnPIZaFF1DieVHFmYGqnL2tNJ/hQ9yxOXVH347+gnc6lek hz5hCXQwxqMZo6aqyvEgbPbM9/oJHzLoVYyvYX3Hvam8VgLB6ZaJAGAwsAtrCmIRgPs9 uk4mtwfwDprONFcMul1m2gANT26ZPyzQI+QwhX2lBvwhNGsw37+yFYzMd2ofa6W3oU/1 6b+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=yll9ik5nj/RKHcc0X7snHFL6YFsTYxSrnn00ighgwfI=; fh=XBbqqbjR4GSvHAHDNJgFyWZ8SAzjGmTEgS58s1j/Tr4=; b=gYWb9hIC6c7YGSGuscFB2wr1plP0NvACRDyqStZ7WpAYMFt3RPzdVndM+wVQ0fMCHW LES7HiBMuIpbUGzM10mxxbvxRUX/rTYorm77Al5u0dry02DJTLKY3e5VVp2s4rVKkKsC VOkZlSWKd+VW83GYtaUTGJSKbrLEOfHVTXBU8zNSjaCCwAdhaJ/J9BhZRbZsLyrPBTOM E04lsVwEj135BHsayINcbR04jrLmnkOQwfBR+68oh7Z8qeFCXnHEWMZC7wSaqXbSJy2D oAfQntuP3PuEECjO87+opI3CIGMUYyw2Ln2jBvaQ6Co+7w9/YLB5SQQFGgghmLAdjPc+ R3Uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=AF5FmNad; spf=pass (google.com: domain of linux-kernel+bounces-14605-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-14605-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id i18-20020aa79092000000b006cbd40b46basi20085843pfa.133.2024.01.02.08.29.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 08:29:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-14605-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=AF5FmNad; spf=pass (google.com: domain of linux-kernel+bounces-14605-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-14605-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 9B5FD283A78 for ; Tue, 2 Jan 2024 16:29:19 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 49A3014F9A; Tue, 2 Jan 2024 16:29:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="AF5FmNad" X-Original-To: linux-kernel@vger.kernel.org Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8155814F6D; Tue, 2 Jan 2024 16:28:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=yll9ik5nj/RKHcc0X7snHFL6YFsTYxSrnn00ighgwfI=; b=AF5FmNadQ4yqLEuhUY/zMGTyPs KmYUrp2TmS7ASCybxrFRTFo/XULYv8YOqGtE+7du+cJbNb98QyqgZ/wvX7vMGwxzngrg+9PpOeuYX TO6HrcMaTP+JnPLn9AJJ2sM8x1/xXQmIWbQFd+Fkqk1ShR8jehEi1jj9/AZwZRHESHNdNrK7JpV5C 1ilSKnKVIJ1KQJYbBe2aUd5JDdV6FT8v/msk4l2U/5pZUVmTWkql5ZATnRPEH5HEk6yED1XCHp2dQ AjJWvYtkEst8W//mwWyPinKVTBmDb/KHcRqyWcj0uYJ9DBr+xW1e2Zqx4kOkrGk1Oc52l2Ql7tkCP a3TRSgiA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rKhdE-00AfG7-3t; Tue, 02 Jan 2024 16:28:44 +0000 Date: Tue, 2 Jan 2024 16:28:44 +0000 From: Matthew Wilcox To: Markus Elfring Cc: virtualization@lists.linux.dev, linux-fsdevel@vger.kernel.org, kernel-janitors@vger.kernel.org, Miklos Szeredi , Stefan Hajnoczi , Vivek Goyal , LKML Subject: Re: [2/2] virtiofs: Improve error handling in virtio_fs_get_tree() Message-ID: References: <5745d81c-3c06-4871-9785-12a469870934@web.de> <54b353b6-949d-45a1-896d-bb5acb2ed4ed@web.de> <691350ea-39e9-4031-a066-27d7064cd9d9@web.de> <9b27d89d-c410-4898-b801-00d2a00fb693@web.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9b27d89d-c410-4898-b801-00d2a00fb693@web.de> On Tue, Jan 02, 2024 at 11:47:38AM +0100, Markus Elfring wrote: > > Do you consider more clarity in your argumentation? > > It is probably clear that the function call “kfree(NULL)” does not perform > data processing which is really useful for the caller. > Such a call is kept in some cases because programmers did not like to invest > development resources for its avoidance. on the contrary, it is extremely useful for callers to not have to perform the NULL check themselves. It also mirrors userspace where free(NULL) is valid according to ISO/ANSI C, so eases the transition for programmers who are coming from userspace. It costs nothing in the implementation as it is part of the check for the ZERO_PTR. And from a practical point of view, we can't take it out now. We can never find all the places which assume the current behaviour. So since we must keep kfree(NULL) working, we should take advantage of that to simplify users.