From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752426AbbF2GDa (ORCPT <rfc822;w@1wt.eu>);
	Mon, 29 Jun 2015 02:03:30 -0400
Received: from mout.web.de ([212.227.15.14]:59496 "EHLO mout.web.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751159AbbF2GDX (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 29 Jun 2015 02:03:23 -0400
Message-ID: <5590DF8A.8030503@users.sourceforge.net>
Date: Mon, 29 Jun 2015 08:02:50 +0200
From: SF Markus Elfring <elfring@users.sourceforge.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Alexey Kardashevskiy <aik@ozlabs.ru>,
        Alex Williamson <alex.williamson@redhat.com>, kvm@vger.kernel.org
CC: LKML <linux-kernel@vger.kernel.org>, kernel-janitors@vger.kernel.org,
        Julia Lawall <julia.lawall@lip6.fr>,
        Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: vfio: powerpc/spapr: One function call less in tce_iommu_attach_group()
 after kzalloc() failure
References: <5307CAA2.8060406@users.sourceforge.net> <alpine.DEB.2.02.1402212321410.2043@localhost6.localdomain6> <530A086E.8010901@users.sourceforge.net> <alpine.DEB.2.02.1402231635510.1985@localhost6.localdomain6> <530A72AA.3000601@users.sourceforge.net> <alpine.DEB.2.02.1402240658210.2090@localhost6.localdomain6> <530B5FB6.6010207@users.sourceforge.net> <alpine.DEB.2.10.1402241710370.2074@hadrien> <530C5E18.1020800@users.sourceforge.net> <alpine.DEB.2.10.1402251014170.2080@hadrien> <530CD2C4.4050903@users.sourceforge.net> <alpine.DEB.2.10.1402251840450.7035@hadrien> <530CF8FF.8080600@users.sourceforge.net> <alpine.DEB.2.02.1402252117150.2047@localhost6.localdomain6> <530DD06F.4090703@users.sourceforge.net> <alpine.DEB.2.02.1402262129250.2221@localhost6.localdomain6> <5317A59D.4@users.sourceforge.net> <55901E68.80205@users.sourceforge.net> <55901FAC.1090109@users.sourceforge.net> <5590862A.3010603@ozlabs.ru>
In-Reply-To: <5590862A.3010603@ozlabs.ru>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:8ubaWjmgrYoa+wFpElAqrIMhrJ2dUr181n2L0aCWgE/xBw3Fz9k
 Q/RpmYQv8KfeAPScfaIoeFR2Z/Ongy+hxR9oaR8GtbcOVZXHRDBcZVQvMUbgT4lu8Ykfe2e
 miL2aFr8rHiKHlXllpI/2nWtIqS76vZfhu3OUfU712QRbRE1N9/VnsJAtRf9n9+haAC9ut/
 csqHZ24tldklQQQSK5abA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:0561U+dCDXI=:7t9vqSKYcG1+icw9DdS+Jw
 SixLPrcevLp4vMkDYMOJG9KPpiwuVhbskYmAHlPU1wOMzc5FslyEfNkoJg9OYo5bI4pVoVHRd
 HccHvH06rKpKx3yEZxgOM5fBbxG1TLTduVMaS+pfXdlZEPihgdy8kKATrjz0W4BfWoRMmW0Gp
 0zpDdehbaX61xntIH84sdAsjyHCXPjYCZci4yASgit0Gmoq+XSUbY0s8v3jU6UWYz4d3OxH85
 W6SrJSYo9yDU7qINLtPhIdLr8CoEI6CeTv2yE1Z97WBtcGuemZ10gCN1jY5x/TBkqpleCTh0E
 dAzecJ0/o1PU7sN7S05TZxrYARCdHCna5fg1hGzH3ZjJdehIQ+3HvA4xXwpUmCXZN9dZOUE5f
 NZiFFwYzno3XRVOc6U4/lOGaIN5F2yHVnc8MCXPrXL3qPg46MjIjpRAYdv6ccU/LC1adgPinU
 XQzigicgZ3aREVp8Y8Y8+rxLUJ6IAfxuoncSo+rubKWGmDMdgYuU+Kkfg2h/mQyZ8T69Cr/xd
 MmCS0c2+ARHyB/RqVDotlFQx/qgCjmE7hCeLneGEnLu5iHLOhFzqe2dS0+DRPUvwBUMH+Hzk/
 eOY4yEmrGWxnvukZvYXwkjrX9Fa6rdi6woLJ+kPFARoMBZ3s6nse4dkgfOEIiqJw3MiirD0od
 IBTCy/hhqqxIDBRdyySac15UtwrJP0ZfJM3/AK9xdArr5QZhaninoRqwOXneIVY/sMsE=
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> tcegrp will be NULL and kfree() can handle this just fine

The affected function did not show this API knowledge, did it?


> (is not it the whole point of this patchset
> - remove the check and just call kfree() even if the pointer is NULL?).

Partly, yes.


> And if you wanted another label,

I suggest this to improve corresponding exception handling.


> than the existing one should have been renamed to "free_exit" or "free_unlock_exit"
> and new one would be "unlock_exit".

I chose a smaller change at this place.

I am not familiar enough with other called functions there at the moment.
Are the remaining goto statements also update candidates?

Regards,
Markus