Received-SPF: pass (google.com: domain of linux-kernel+bounces-22512-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <1910913d-c3fe-45ab-a871-deda5318e2cf@web.de>
Date: Wed, 10 Jan 2024 18:08:17 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Drivers: hv: vmbus: One function call less in
 create_gpadl_header() after error detection
To: Michael Kelley <mhklinux@outlook.com>, linux-hyperv@vger.kernel.org,
 kernel-janitors@vger.kernel.org, Dexuan Cui <decui@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, "K. Y. Srinivasan"
 <kys@microsoft.com>, Wei Liu <wei.liu@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>, "cocci@inria.fr" <cocci@inria.fr>
References: <6d97cafb-ad7c-41c1-9f20-41024bb18515@web.de>
 <SN6PR02MB4157AA51AD8AEBB24D0668B7D4692@SN6PR02MB4157.namprd02.prod.outlook.com>
 <82054a0a-72e5-45b2-8808-e411a9587406@web.de>
 <SN6PR02MB4157CA3901DD8D069C755C72D4692@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Language: en-GB
From: Markus Elfring <Markus.Elfring@web.de>
In-Reply-To: <SN6PR02MB4157CA3901DD8D069C755C72D4692@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:2x/ntfbrdNw=;+ZwzS1arjIKAorVjx3qIfv7jem7
 rTtEEMGp2Euk71hadmLZbIixqIn4LEMHu0UqAgPbe/q7k+h6KTTkc0UTns7PlpihYme4+6YR8
 +7ntDyLWxgjkDkHBCRmF/Np0xMO0eaH4KKkzafEZNDIyVyALb8oqUYkXRXWG4ri1gzYtUNDCO
 fE5rdEtb3a3/7l7lsLeKussW/8BuZ9EiHSpmbnnZEwQEsLmOCNaAQ5pr75v92xmTWvANk5wvv
 19KpQhtPup3YhkvJ8pS9uC4GhqKcollq+ppyeY9ingTd6OL4l459RmG3AdfP6o81o2pZ0LWv5
 qKHZSyiDVUHrGnqEKajxAS4TlLCSx3LScC1mvGWJmoKp4IGpgQH+Uoul163CpPueqy0lSQJs1
 INTnsbmRi7JfJkda+2TNMbADTxTGweF7nDffbzksFNFomqxJaNb4baR8fJPgDMkI2902Gfdyd
 b9CxOg5+ZnHIC68CbHoA34oEWvPksm9H44BF6IfFdH35/hh0UeZqU24sy2Q4gMxS4wQkEzAmX
 PWCEDY64U5Eatlv/JQJB/ZhuP2VHuGzYu8GXn7AMV4XqEffkZVoDyPsATY7QYUxBTBfqdlnaK
 XpPqZWYLvrnusjLyucaTj8MgRZK6llsY0ayPivMgTYtsZKGweNWZ47OPpJyurqH3B2pBhw2Iv
 JwOxOLy4NKmyUdnGKE5coWB80nt747zct7D+dXNhCGD9fldlgwpTX6yTCOow+MZl/J1Q9BCb0
 tsrPIcTEaUE3tqTUeT/9xtoloi7h/WkWwEyYwm5+Z3B5EeWVddB+wD8in7L82+WL3dNiMHbj8
 JC3FQo2JqFgMyPcFLcpjW5CuNvG7UOxnCdKTpJo3qzU4wyEkIowh4IbWNcrBIsj4lb2SZk7N9
 JJJYu7tVad8R9xvJSllvc95+kAf2ZFr3HCSCSzrjJpPrL99VrQHu9UeYXqDqlJ/NbHwpqLGeE
 KPWyQRbk2ZNBzz3U+ylEnvyCcZU=

> It occurred to me overnight that the existing error handling
> in create_gpadl_header() is unnecessarily complicated.  Here's
> an approach that I think would fix what you have flagged, and
> would reduce complexity instead of increasing it.  Thoughts?

I find this development view interesting.


> diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
> index 56f7e06c673e..44b1d5c8dfed 100644
> --- a/drivers/hv/channel.c
> +++ b/drivers/hv/channel.c
> @@ -336,7 +336,7 @@ static int create_gpadl_header(enum hv_gpadl_type ty=
pe, void *kbuffer,
>  			  sizeof(struct gpa_range) + pfncount * sizeof(u64);
>  		msgheader =3D  kzalloc(msgsize, GFP_KERNEL);
>  		if (!msgheader)
> -			goto nomem;
> +			return -ENOMEM;
>
>  		INIT_LIST_HEAD(&msgheader->submsglist);
>  		msgheader->msgsize =3D msgsize;
> @@ -386,8 +386,8 @@ static int create_gpadl_header(enum hv_gpadl_type ty=
pe, void *kbuffer,
>  					list_del(&pos->msglistentry);
>  					kfree(pos);
>  				}
> -
> -				goto nomem;
> +				kfree(msgheader);
> +				return -ENOMEM;
>  			}
>
>  			msgbody->msgsize =3D msgsize;
> @@ -416,8 +416,8 @@ static int create_gpadl_header(enum hv_gpadl_type ty=
pe, void *kbuffer,
>  			  sizeof(struct vmbus_channel_gpadl_header) +
>  			  sizeof(struct gpa_range) + pagecount * sizeof(u64);
>  		msgheader =3D kzalloc(msgsize, GFP_KERNEL);
> -		if (msgheader =3D=3D NULL)
> -			goto nomem;
> +		if (!msgheader)
> +			return -ENOMEM;
>
>  		INIT_LIST_HEAD(&msgheader->submsglist);
>  		msgheader->msgsize =3D msgsize;
> @@ -437,10 +437,6 @@ static int create_gpadl_header(enum hv_gpadl_type t=
ype, void *kbuffer,
>  	}
>
>  	return 0;
> -nomem:
> -	kfree(msgheader);
> -	kfree(msgbody);
> -	return -ENOMEM;
>  }
>
>  /*
>

Should up to two memory areas still be released after a data processing fa=
ilure?

Regards,
Markus