Received-SPF: pass (google.com: domain of linux-kernel+bounces-14615-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <a08b7922-c28d-4667-b7f3-a4064ff7d6b3@web.de>
Date: Tue, 2 Jan 2024 17:50:31 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [2/2] virtiofs: Improve error handling in virtio_fs_get_tree()
Content-Language: en-GB
To: Matthew Wilcox <willy@infradead.org>, virtualization@lists.linux.dev,
 linux-fsdevel@vger.kernel.org, kernel-janitors@vger.kernel.org
Cc: Miklos Szeredi <miklos@szeredi.hu>, Stefan Hajnoczi
 <stefanha@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
 LKML <linux-kernel@vger.kernel.org>
References: <c5c14b02-660a-46e1-9eb3-1a16d7c84922@web.de>
 <5745d81c-3c06-4871-9785-12a469870934@web.de>
 <ZY6Iir/idOZBiREy@casper.infradead.org>
 <54b353b6-949d-45a1-896d-bb5acb2ed4ed@web.de>
 <ZY7V+ywWV/iKs4Hn@casper.infradead.org>
 <691350ea-39e9-4031-a066-27d7064cd9d9@web.de>
 <ZZPisBFGvF/qp2eB@casper.infradead.org>
 <9b27d89d-c410-4898-b801-00d2a00fb693@web.de>
 <ZZQ5vKRcq9kkQxSD@casper.infradead.org>
From: Markus Elfring <Markus.Elfring@web.de>
In-Reply-To: <ZZQ5vKRcq9kkQxSD@casper.infradead.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:INHlZ34bTrY=;zJ6eL3Bj8LtupwNNsZ/tNpt+E2E
 rhyAK3+huAVszX+0JbpGi64wipqZXXquvT4FmqAX7pGXUkHtAEoOHZIokacWsiAyrws3VQQeg
 DIXuuLYzp0aIuiVIkLmUmqRsavOE26MAy5tZdoMkNJMu7znwwSxof//lHLJHqspM7G04K+1CB
 lgysUAozHm8yIUawO6/9T0gSrzzF3TXmYjwKDkCpGct18rREpOAfzaO6oY5QVX++Bd9W4CHC+
 NbE6zpqSx/pi/ylp/zDkcYgF07rRsGZHbP2E9yASNv43STyAIK3V2W/A7tStBaWWfle82L5XR
 bNWST7bzpauZtH3bauwe0HWUvoMQvjV0qbllMqX8INYz5x4NR87GRSm+VnS6UwEeWSm0v3fRJ
 +iBHgX0EX3lWuJoBp/eu6Tf5ua9nLns/mUzPDtxetGhdLz9LdfLdYX3bv4W7/1IuLOOWuZ/Ap
 py6IlmAMef9Pd1cL9RM1twOr90kLwBsxQbKM/1TqV9AlEh5BGM1tEZHLTouOTfEmA7JdU7tSH
 RWJj9NRY82jXBs2s2ZomWUoqPdjLvmww41zM80qegF4RQrmASVMjj3DFJJJ6JTcTZ4MXDgJK7
 y7GPQ0WHvENX0DUd7xdEHlrViDvcbHjaoEnbiedprJ0iYRZB2RmynuzyeNSTJGtcP0xakIsFD
 Nhyv/faX+I0RWr8Aiz2KX3susJR7RPm4y8nN4i40T4KSJITTgmtrYsTvpuEl9lzcaQdD7Rdfk
 +BjKi+dBPasvlXNEp4iIxEAWpnqdPu/AJp5iJ3UJaC+GEpPZQ1rUNgu/BGtqaQddSiCMLuOXr
 r0CEC5MpHK2gxv/aBAyEJWHVaQMwQGYDXQaR3zVstjx2w1G+f2VFo7fR7HG+hpV6INVeI4flw
 0rkTsIFFgwiL75v4U80TKk11B71DGoSjAR1Cg0V2UtZTsoLK8hSh4YWuF83pWInQeZHeSUoIB
 eLOjiw==

>> It is probably clear that the function call =E2=80=9Ckfree(NULL)=E2=80=
=9D 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 i=
nvest
>> development resources for its avoidance.
>
> on the contrary, it is extremely useful for callers to not have to perfo=
rm
> the NULL check themselves.

Some function calls indicate a resource allocation failure by a null point=
er.
Such pointer checks are generally performed for error detection
so that appropriate exception handling can be chosen.


>                             It also mirrors userspace where free(NULL)
> is valid according to ISO/ANSI C, so eases the transition for programmer=
s
> who are coming from userspace.  It costs nothing in the implementation
> as it is part of the check for the ZERO_PTR.

How many development efforts do you dare to spend on more complete
and efficient error/exception handling?

Regards,
Markus